This is the mail archive of the
mailing list for the Cygwin project.
[ANNOUNCEMENT] Updated: libtool-devel-20030216, libltdl-20030216
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: cygwin at cygwin dot com
- Date: Sat, 22 Feb 2003 17:48:45 -0500 (EST)
- Subject: [ANNOUNCEMENT] Updated: libtool-devel-20030216, libltdl-20030216
- Reply-to: cygwin at cygwin dot com
libtool-devel has been updated to the 20030216 CVS codebase, as well as
libltdl3. The 20030216 release has been in 'test' for a week, with no
ill effects -- save a known problem with wacky pseudo-cross-compiler
setups (see 'Open issue' below).
Note that libtool-devel-20030103 depends on autoconf-2.55 or newer
(currently, the only cygwin official release of autoconf that satisfies
this is autoconf-devel-2.57-1), and automake-1.7.1 or newer.
Changes from 20020103-1
o updated to 20030216 CVS
- all of the previous changes in 20021227-1 have been accepted
into libtool CVS HEAD (and are therefore present in 20030216)
- all of the changes described below have also already been
accepted into CVS HEAD.
o libtool-1.5-alpha is imminent...
o Fixes the "relink .exe files over and over and over and over" problem.
See http://cygwin.com/ml/cygwin/2003-02/msg00130.html for more info.
o 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 speed problem with the internal "win32_libid()" routine is partially
fixed -- approx 35% speedup. Ralf Habacker is working on some
modifications to the official fileutils distribution (specifically,
file.exe) that should allow an additional 8% speedup without additional
changes to libtool.
==IMPORTANT== see NOTES below.
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. Save it and run setup, answer the questions and pick
up 'libtool-devel' from the 'Devel' category. Because this is an
experimental 'test' release, you must click on the 'Exp' radio button in
order for the 20021111-1 version of libtool-devel to show up, or click
on the spinner (version number) until 20021111-1 is displayed.
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations. This means that you will need
to find a mirror which has this update.
In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.
In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is already
In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date.
If one of the above doesn't have the latest version of this package
you can either wait for the site to be updated or find another
Please send questions or comments to the Cygwin mailing list at:
cygwin at sources dot redhat dot com . If you want to subscribe go to:
http://cygwin.com/lists.html I would appreciate if you would use
this mailing list rather than emailing me directly. This includes
ideas and comments about the setup utility or Cygwin in general.
If you want to make a point or ask a question the Cygwin mailing
list is the appropriate place.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
To unsubscribe to 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:
cygwin-announce-unsubscribe-YOU=YOURDOMAIN dot COM at cygwin dot com
Changes from 20021227-1
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 @^
Changes from 20021111-1
o -export-symbols <a def file> now works properly (it's been broken
for over two years...)
Important notes from 20021111:
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 (*)
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. (**)
(*) 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.
(**) 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.
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"
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html