This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
[ANNOUNCEMENT] Updated: libtool-devel-1.5-3 [Requires cygwin-1.5.3+]
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: cygwin at cygwin dot com
- Date: Fri, 5 Sep 2003 01:45:16 -0400 (EDT)
- Subject: [ANNOUNCEMENT] Updated: libtool-devel-1.5-3 [Requires cygwin-1.5.3+]
- Reply-to: cygwin at cygwin dot com
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.)
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:
cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com
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"
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/