Updated: libtool-devel-1.5.6-3

Charles Wilson cwilson@ece.gatech.edu
Thu Jul 8 15:59:00 GMT 2004

The libtool-devel package contains the 1.5.6 version of libtool, a 
cross-platform tool for building libraries (shared and otherwise).  It 
enables relatively trouble-free builds of DLLs on cygwin and mingw.

Changes from 1.5-3:

o routine update to latest release version
o Includes Gerrit's "expat" fix -- but only the first part of the patch:
o Official libtool NEWS from 1.5.2, 1.5.4, 1.5.6:
   * Installs libltdl files properly in $prefix/share/libtool/libltdl.
   * libltdl correctly guesses the extension for loadable modules again.
   * lt_dlrealloc is an official part of the libltdl API.
   * --tag, --silent and --debug options are preserved and reused when
     libtool calls itself for relinking etc.
   * `-pthread' and similar options are honoured when linking shared
   * -no-suppress in compile mode shows compiler output for both PIC and
     non-PIC object compilation.
   * New link mode option `-precious-files-regex' to prevent accidental
     removal of files you want to keep, such as test coverage data, from
     the temporary output directory.
   * Bug fixes.
o see NOTES below, for



To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .


If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


If you need more information on unsubscribing, start reading here:


Please read *all* of the information on unsubscribing that is available
starting at this URL.



1) Open issue: pseudo-cross compiler setup doesn't work (e.g. setting 
CC='gcc -mno-cygwin' and expecting a mingw output doesn't work, although 
it's unclear whether it SHOULD work, even if at some point in the past 
it did.) The binary wrapper program hardcodes "/bin/sh" -- which is not 
a valid pathname for a -mno-cygwin program. It'd be best to compile the 
wrapper with plain "gcc" -- But without making a distincution between 
the buildplatform compiler and the hostplatform compiler (e.g. without 
using --build= --host=), we can't know about the need for this 
distinction. IMO, fixing the "relink .exe ad nauseum" problem is more 
important than this corner case -- and there are other ways of 
addressing this corner case, which do not involve changes to libtool.


o adds partial support for including .rc files and using windres
   to add resources to executables and libraries.  You still must
   add something like the following to your Makefile.am file:

   LTRCCOMPILE = $(LIBTOOL) --mode=compile $(RC) \
      `echo $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) |\
          sed -e 's/-I/--include-dir /g;s/-D/--define /g'`

and then explicitly include a build rule:

   %.o : %.rc
         $(LTRCCOMPILE) -i $@ -o @^

o -export-symbols <a def file> now works properly (it's been broken
   for over two years...)

o DESIGN DECISION: (this is a a change from pre-20021111 behavior)
     libtool will refuse to create a shared library if any of its
     dependencies are available only as static archives.  DLLs may
     only depend on other DLLs (*)

(*) This is a good idea. But, we need workarounds for the standard 
runtime libs like libgcc.a, libstdc++.a, etc. These workarounds are 
implemented in this libtool release.

o correctly identifies import libraries as "shared objects", so that
   libtool's new "DLLs may only depend on other DLLs" behavior isn't
   triggered with fatal results when a target DLL's dependencies are
   satisfied by import libs.

o Skips the "DLLs may only depend on other DLLs" check when the
   dependency is one of the "standard" runtime libs which are currently
   available only in static form (libgcc.a, libstdc++.a, etc) on

o Isn't "confused" by the libtool .la files supplied with cygwin's gcc,
   even though they only specify static archives  (e.g. libstdc++.la
   lists "libstdc++.a" but not "cygstdc++.dll" [which is good because
   cygstdc++.dll doesn't exist]).

o No longer records compiler builtin library paths or compiler-generated
   deplibs (like -luser32 -lgcc) in the "dependency_libs" variable in
   generated .la files.


Two selftest failures (longstanding, not regressions)

I fixed one bug, but another showed up: $PATH doesn't
get set properly when running this test...This test
used to get skipped on cygwin, but no longer?

compile mode seems okay
install mode seems okay
link mode *always* fails -- like this:
   "failed: mkdir .libs
    gcc -o hell.exe -g -O -Wl,-someflag=test foo.o"
?? *mkdir* fails??
But it works fine in compile mode---
   "passed: mkdir .libs
    gcc -c "-DVAR= test    " foo.c  -DPIC -o .libs/foo.o
    gcc -c "-DVAR= test    " foo.c -o foo.o >/dev/null 2>&1"

More information about the Cygwin-announce mailing list