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 Date: Mon, 11 Sep 2000 23:42:02 +0100 From: "Gary V. Vaughan" To: "Charles S. Wilson" Cc: cygwin AT sources DOT redhat DOT com, automake AT gnu DOT org Subject: Re: libtool Message-ID: <20000911234202.C606@demon.co.uk> References: <20000907133430 DOT 25505 DOT qmail AT web119 DOT yahoomail DOT com> <20000907185550 DOT O7695 AT demon DOT co DOT uk> <20000908012740 DOT A26790 AT demon DOT co DOT uk> <39BBC382 DOT 4A2E53E3 AT ece DOT gatech DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39BBC382.4A2E53E3@ece.gatech.edu>; from cwilson@ece.gatech.edu on Sun, Sep 10, 2000 at 01:23:14PM -0400 X-Operating-System: Linux oranda 2.2.13 On Sun, Sep 10, 2000 at 01:23:14PM -0400, Charles S. Wilson wrote: > I don't believe the following behavior is possible in the current > libtool. However, if it is, please correct me. Nope. How can libtool know what types of library an object will eventually be linked with. libtool --mode=compile gcc -c foo.c -o foo.lo Perhaps we could teach automake to analyse the make rules and pass more details to libtool on the link line? It would be quite a big job, and I am no Perl hacker =(O| We would need something like: libtool --mode=compile gcc -c foo.c -o foo.lo --links-with=libbar.la Hmmm. Even that is not enough. automake would also need to analyse the link command to determine whether the user has specified -static to force static linking -- and probably a buch of other complications I didn't consider. > In the upcoming libtool (1.4?) it would be nice on cygwin/windows-ish > platforms, if the libfoo.la file could instruct libtool that it may need > different -Ddefines when compiling an object file that is to be linked > to a static lib or to a dynamic lib (dll). Have you seen the recipe I am using for m4-1.5? Or in my snprintfv library? (both available from my home page). I have also written a chapter about using GNU autotools on Cygwin for the forthcoming book `Autoconf, Automake and Libtool' from NewRiders, which describes the systewm I use in some detail.. > For instance, on cygwin, if compiling/linking my-file.c and I want to > link to libz statically, I need the following (when compiling/linking by > hand, no libtool): > > gcc -c -DZLIB_STATIC -o my-file.o myfile.c > gcc -static -o my-file.exe my-file.o -L -lz > > If I want to link dynamically, I need: > > gcc -c -o my-file.o myfile.c > gcc -o my-file.exe my-file.o -L -lz > > That is, both the compile and the link steps are different. Is it > possible for this information to be embedded in libfoo.la (libz.la in > this case) -- so that libtool knows that 'statically linked packages > that depend on libz must have -DZLIB_STATIC in the compile step', while > 'dynamically linked packages that depend on libz need no special > -Ddefines in the compile step'. > > Similarly, you need -DPNG_STATIC for libpng, -DJPEG_STATIC for libjpeg, > etc... At the object level, often it is only the developer who really knows exactly which combination of libraries a module will eventually link with. And even they may not be sure which combination is present on one of their user's machines at install time. You are correct in that this would be a nice feature -- but it is only necessary for Win32 systems, and is *a lot* of work, so don't hold your breath. Cheers, Gary. -- ___ _ ___ __ _ 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 -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com