This is the mail archive of the
mailing list for the Cygwin project.
Re: ok, new libtool for cygwin updates
- To: "edward" <tailbert at yahoo dot com>,<cygwin-apps at cygwin dot com>
- Subject: Re: ok, new libtool for cygwin updates
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Sat, 10 Mar 2001 21:14:34 +1100
- References: <022b01c0a86a$d09a8080$9865fea9@edward>
I'm not sure whether you want blow by blow bug reports, or a
So far, I've pulled down CVS HEAD automake, extracted your archives
automake directory into the automake source tree, done
(this was to get your hacked automake installed rather than fiddle round
with calling a non-installed one..
and had the following tests fail:
I don't know if that's expected on cygwin, with or without your patch,
but I figured you'd like to know.
I'm running a fairly standard cygwin install, a few mount points (all
binary at the moment) here and there, and CYGWIN=ntsec. Oh, no
networking, all file paths are local.
Let me know if you want a cygcheck etc.
I'm going to have a quick look at why these fail, and then onto libtool.
----- Original Message -----
From: "edward" <email@example.com>
Sent: Friday, March 09, 2001 6:30 PM
Subject: ok, new libtool for cygwin updates
> well peeps.
> i actually browsed through the libtool mail archives and read the note
> cygwin specific things (especially the mail/cygwin32 file).
> here is a set of updates to libtool.m4, ltmain.in (and automake.in)
> does just about all of it, as far as I can tell. the libtool check
> passes completely (don't forget to use the hacked automake).
> libtool highlights:
> * use libFOO.dll.a for import libs, libFOO.a for static libs,
> cygFOO-version.dll for dlls
> * install cygFOO-version.dll into lib/../bin/cygFOO-version.dll
> * actually use .lai files! sets dlname to ../bin/cygFOO-version.dll
> note that the key thing i tested for was the creation of dll's using a
> generated def file, although the libtool test suite *does* pass. note
> handling dependencies modules is still not robust. it works if the
> already in memory, otherwise no. still need to modify libltdl to
> cygwin cases specifically. bleh. so if the libtool test suite fails on
> on the execute from installed test, there you go (just nuking the .la
> works just fine by the way. windows already knows about dependency
> as far as the automake patches go, it's mostly to allow the libtool
> suite to pass. i did make a change to the way .exe targets are
> instead of the automake hack of re-writing all foo_PROGRAM rules to
> EXEEXT, i modified it to generate an internal rule called
> this is used for targets like clean. for the standard targets, libtool
> breaks horribly with the original hack due to the generation of script
> wrappers for apps that use shared libraries, if the EXEEXT hack is
> this isn't the best thing i can think of, but it should do for now.
> automake highlights:
> * generate internal macros am_foo_PROGRAMS (e.g. am_bin_PROGRAMS)
> .EXEEXT'd versions of foo_PROGRAMS. this is used only in the clean
> the moment.
> * you also get my partially specified conditional target generation
> automake mail list for details)
> instead of posting patches, i am posting all of libtool/libtool.m4,
> libtool/ltmain.in and automake/automake.in, because you may already
> patched versions of these laying around. this should allow you to drop
> into your testing environment and see if it works.
> again, these are against the latest CVS versions
> ps. i've removed the previous set of test libtool stuff from my
> pps. don't forget to regenerate the Makefile.in files in the libtool
> suites (demo, depdemo, mdemo, etc.) using the hacked automake.
> mdemo-*.tests will fail.
> ppps. some final notes. from what i can tell, the usage
of -no-undefined is
> mandatory on platforms like aix and windows when generating dlls. this
> why the mdemo test on foo1.la builds a static archive. but in simple
> like foo1.la, dlopen seems to work. cheers.