Updated: libtool-devel-1.5-3 [Requires cygwin-1.5.3+]

Charles Wilson cwilson@ece.gatech.edu
Fri Sep 5 05:44:00 GMT 2003

The libtool-devel package contains the 1.5 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.

This release is built against the cygwin-1.5.x kernel; it will not work 
with 1.3.22.  (Yes, I know that libtool is mostly a big shell script. 
But it also includes the dynamic loader library, cygltdl-3.dll.)


* compiled against cygwin-1.5.2 kernel
* Documentation moved to /usr/share/*
* includes some patches from libtool-CVS:
   - Max Bowser's library search order fix
   - a fix for tests/dryrun.
* bugfix for wrapper executable when wrapper is invoked
   via ${PATH}. Submitted to libtool cvs.

See NOTES below for older news, and selftest results.

Charles Wilson
libtool-devel volunteer maintainer for cygwin

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 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 the above URL.



1) Building an executable,
that links against a shared library that is part of the same package,
where the source file(s) are in a different subdir than the makefile
that builds the executable, doesn't work. (yeah, real "common" case.
Known to affect expat)  Example:

<top-sourcedir>/sharedlib/<library files, own Makefile.in>

<top-sourcedir>/Makefile.in contents:
default:  buildlib foo/foo

buildlib: $(LIBRARY)

all: $(LIBRARY) foo/foo

For more info, see

2) 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 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.  (**)

(**) e.g. if cygwin's gcc-3.2 had been built with this version of
libtool, then /usr/lib/libstdc++.la wouldn't be so "weird" -- even
though cgf removed it entirely from the more recent releases of gcc-3.2
for cygwin. However, if you've got an old version of cygwin-gcc-3.2,
this libtool won't croak.


Three selftest failures (two longstanding, not regressions; one recent
due to changes [bug?] in cygwin1.dll)

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