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.)
CHANGES:
* 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.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
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:
[EMAIL PROTECTED]
If you need more information on unsubscribing, start reading here:
http://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available starting at the above URL.
NOTES: -------------------------
KNOWN ISSUES: ==================================================================
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>/Makefile.in <top-sourcedir>/foo/foo.c <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 http://www.cygwin.com/ml/cygwin/2003-04/msg01247.html
----------------------------------------------------------------- 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.
NEW FEATURES: ==================================================================
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 cygwin/mingw.
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.
SELFTEST FAILURES =====================================================================
Three selftest failures (two longstanding, not regressions; one recent due to changes [bug?] in cygwin1.dll)
build-relink2: ------------------- 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?
quote:
-------------------
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"