ok, new libtool for cygwin updates

[edward]

well peeps.

i actually browsed through the libtool mail archives and read the note about
cygwin specific things (especially the mail/cygwin32 file).

here is a set of updates to libtool.m4, ltmain.in (and automake.in) that
does just about all of it, as far as I can tell. the libtool check suite
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 user
generated def file, although the libtool test suite *does* pass. note that
handling dependencies modules is still not robust. it works if the module is
already in memory, otherwise no. still need to modify libltdl to handle
cygwin cases specifically. bleh. so if the libtool test suite fails on mdemo
on the execute from installed test, there you go (just nuking the .la file
works just fine by the way. windows already knows about dependency libs).

as far as the automake patches go, it's mostly to allow the libtool test
suite to pass. i did make a change to the way .exe targets are treated.
instead of the automake hack of re-writing all foo_PROGRAM rules to append
EXEEXT, i modified it to generate an internal rule called am_foo_PROGRAM.
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 kept in.
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) which hold
.EXEEXT'd versions of foo_PROGRAMS. this is used only in the clean target at
the moment.
* you also get my partially specified conditional target generation (see
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 have
patched versions of these laying around. this should allow you to drop those
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 homepage.

pps. don't forget to regenerate the Makefile.in files in the libtool test
suites (demo, depdemo, mdemo, etc.) using the hacked automake. otherwise
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 is
why the mdemo test on foo1.la builds a static archive. but in simple cases
like foo1.la, dlopen seems to work. cheers.

cheers,
edward
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwin-patches.tar.bz2
Type: application/x-bzip2
Size: 101707 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20010308/25b1d323/attachment.bz2>