Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Content-Type: text/plain;
  charset="us-ascii"
From: "Gary V. Vaughan" <gvv AT techie DOT com>
Organization: GNU
To: "edward" <tailbert AT yahoo DOT com>, <cygwin-apps AT cygwin DOT com>
Subject: Re: ok, new libtool for cygwin updates
Date: Sat, 10 Mar 2001 04:08:14 +0000
X-Mailer: KMail [version 1.2]
Cc: <libtool AT gnu DOT org>
References: <022b01c0a86a$d09a8080$9865fea9 AT edward>
In-Reply-To: <022b01c0a86a$d09a8080$9865fea9@edward>
MIME-Version: 1.0
Message-Id: <01031004081408.16449@cain>
Content-Transfer-Encoding: 8bit

Hi Edward,

Your patch is brilliant.  Thankyou.  I need to build a cygwin installation 
before I can test it, but by inspection it looks fine to me.  This stuff is 
all I have left on my Libtool TODO list:  As soon as we have it committed, 
I'd like to make a candidate release for libtool-1.4 so that we can 
concentrate on shaking out any last minute bugs.

Unfortunately, you are way over the FSF 10 line limit guideline for copyright 
assignment =(O|  Would you be prepared to sign paperwork that assigns the 
copyright for your changes to the FSF?  I can email you the request paperwork 
in private if you are agreeable...

Cheers,
	Gary.

On Friday 09 March 2001  7:30 am, edward wrote:
> 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

-- 
  ___              _   ___   __              _         mailto: gvv AT techie DOT com
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary AT gnu DOT org
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc