delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/03/12/02:12:20

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Injected-Via-Gmane: http://gmane.org/
To: cygwin AT cygwin DOT com
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Subject: Re: Bug: Win32 GTK binaries and Cygwin heap error
Date: Wed, 12 Mar 2003 02:12:05 -0500
Lines: 54
Message-ID: <3E6EDDC5.2050204@ece.gatech.edu>
References: <F157s60naVNpqfvYn630000c6b5 AT hotmail DOT com>
Mime-Version: 1.0
X-Complaints-To: usenet AT main DOT gmane DOT org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
In-Reply-To: <F157s60naVNpqfvYn630000c6b5@hotmail.com>

Tim Renner wrote:

> 
> Unfortunately, we have a case where we need to use Cygwin to compile our 
> project because we need the unix and posix support, so -mno-cygwin is 
> out... AND we need to link to GTK libraries that do not require an 
> X-server.  What gets me though is that this DOES work with the older 
> dll, but not with the newer ones...  I'd like to know what changed to 
> cause this difference and if it is a bug or if we just got lucky with 
> the old version ;)

You got VERY lucky. I'd bet that even then, there were subtle bugs 
(memory corruption, races, etc) that were under your radar.

> 
> What I'm seeing for dependencies (Using depends.exe on my test program) 
> is that it depends on Cygwin1.dll and kernel32.dll, as well as 
> libgtk-win32-2.0-0.dll, which does depend on msvcrt.dll, but not 
> cygwin1.dll.  I'm no expert on dll's, so I don't know if that will cause 
> a problem, but from what I understand, that seems okay?

Nope.  Simple example: your app calls printf() which is satisfied via 
cygwin1.dll.  Then, your app calls g_printf (which eventually calls 
system printf -- but in this case, is satisfied by msvcrt.dll).

Which runtime owns stdout?  Do you see both messages, or only one? 
Which one?  Which message is printed first?  Is it *always* printed 
first, or random?  Or do the two messages get intermingled character by 
character?  Or does the app crash? Or deadlock?

------------

It should be possible to 'coopt' the existing MS windowing code from the 
'native' port, to compile a cygwin-based, but MSwindow-not-Xwindow gtk. 
  Tor has two separate #defines throughout the code -- one indicates 
'windowing' and the other indicates 'platform'; you want the first, but 
not the second.  However, no one has attempted to fix the configury bits 
so that you can build gtk as:

   ./configure --without-x --with-mswin

on a cygwin-based (e.g. not MSYS/mingw) system.  If you're willing to 
put in the elbow grease to solve your problem "The Right Way", I'm sure 
Tor will be receptive to your efforts.

FWIW, I posted a patch and method to build glib-2.2.0 on cygwin a few 
months back; that should help a little.  Then you need a non-X but 
cygwin-based libfreetype (being careful not to conflict with the 
existing cygwin-based,X-based libfreetype distributed with 
cygwin-xfree), and then pango, atk, and finally gtk.  It's a big job - 
which is why nobody has done it.

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019