Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com X-Sent: 23 Jan 2001 04:02:17 GMT From: "Kevin Wright" To: "Cygwin-Mailing-List" Subject: Building GNOME on cygwin [WAS RE: Need help compiling glib's libgmodule DLL (gmodule-dl.c)] Date: Mon, 22 Jan 2001 20:04:33 -0700 Message-ID: <000301c084e9$35e943e0$e088f726@holstein-mobile.ASPECTDV.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <008a01c08317$34330820$e088f726@holstein-mobile.ASPECTDV.COM> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Hello, Just a quick update to this message. I finally heard from the famous Edward who managed to build glib on cygwin with DLL's and got testgmodule to pass. With his help, I was able to also build this on my machine. Unfortunately, the only way I got this done was to download his build directory with all of the changes that he made. I'm currently trying to unravel the process by which this was accomplished and when I do I can post more info to the list. In case there are others out there trying to build gnome on cygwin, here is some info on what Edward does to get this to work: e> Generally speaking, I try to modify the code as little as possible. So e> far, I've gone through several methods to try to keep in sync. Right e> now what I'm doing is adding a GNOME_CYGWIN rule to configure.in, then e> adding cygwin specific stuff in CYGWIN.am files, which I keep in the e> directories they are used. e> Basically, I do a cvs update . in the parent directory of all the gnome e> sources, then check to see which files have changed. then ./configure e> in each directory, followed by make, make check, make install. k> 1) In your mail you stated: k> k> e> Final note, you *must* use the latest cvs versions of autoconf, k> e> automake, libtool, fribidi, pango, pkgconf, etc. k> k> I did get the latest libtool from cvs but the version was different k> from what you have. The one I use has some notes on how to create DLL's k> in cygwin (from Gary Vaughn) and when I follow those steps, I can get k> configure to actually say it's going to create shared libs but I k> still have to manually create the DLL's. k> mine: ltmain.sh (GNU libtool) 1.3c (1.852 2001/01/08 01:52:10) k> yours: ltmain.sh (GNU libtool) 1.3.4 (1.385.2.196 1999/12/0721:47:57) e> Yours is the latest. libtool peeps rolled back a few changes, then e> rolled forward some. This is one of the reasons why I avoided going the e> libtool route. They are making a lot of changes, it seems. Same for the e> gcc peeps. gcc -shared is *supposed* to work Real Soon Now as well, in e> most cases. Rather than wait for these 2 groups (which have differing e> philosophies), I chose to go the dllwrap route, which works now. Note e> what I did was to write a wrapper perl script called dllwrap.pl, which e> forwards everything to libtool, except for cases which involve the e> actual building of the dll, and the installation of the dll. libtool e> doesn't make provisions for the dll being installed in a different e> place than the .a file. My dllwrap.pl alleviates the need for pkgconfig e> somewhat, but pkgconfig is the robust solution. e> e> Note, in order to get libtool to create shared libraries, you have to e> specify -no-undefined to the ldflags; also, -expsyms *should* work, to e> specify your own defs file, but it doesn't (last time I checked). e> Basically, libtool needs work. Plus, without your own defs files, e> libtool tries to create its own, but lots of packages already have e> builtin support for windows dlls, so they conflict in those cases. I'll try to provide more info on how this works as I understand it better. Eventually, I'd like to be able to just do ./configure --enable-shared and everything works but that doesn't yet work and, according to Edward, won't until it's changed in the gnome source: e> The *correct* thing to do is have the gnome people accept a redesign of e> the layouts of a number of gnome modules. Basically, keep dlls/shared e> libs separate from programs which are built using them. Doing so will e> automatically enable building using mingw as well as msvc. I don't e> think anyone's volunteered to do this... If anyone's interested, I can put the entire glib project along with Edward's fixes on an ftp site and people can take a look. --Kevin Wright > -----Original Message----- > From: cygwin-owner AT sources DOT redhat DOT com > [mailto:cygwin-owner AT sources DOT redhat DOT com]On Behalf Of Kevin Wright > Sent: Saturday, January 20, 2001 12:29 PM > To: Cygwin-Mailing-List > Subject: Need help compiling glib's libgmodule DLL (gmodule-dl.c) > > > Hello, > > For quite a while now, I've been trying to run gnome under cygwin. > This requires getting libgmodule to compile as a DLL (gmodule is > part of glib). I thought we had a breakthrough when "Edward ?" > posted the following last December 6th: > (http://cygwin.com/ml/cygwin/2000-12/msg00313.html) > > edward> gmodule works for me. > edward> ugh. with spelling errors and all from the cvs source :) > edward> um. i did have to patch gmodule-dl.c and testgmodule.c > edward> um. and gdate.c and gmarkup.c and gstrfuncs.c > edward> and I did have to make tons of changes to the automake/libtool > edward> files to get the dll to build correctly. > [snip] -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple