This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
Yaakov (Cygwin Ports) wrote:
Here's yet another interesting case with libtool-2.2:
"interesting", as in "may you live in interesting times"?
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -pipe -o
libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo
libtool: link: rm -fr .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la
libtool: link: g++ -shared -nostdlib .libs/sources.o
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin
-luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o
.libs/cygfoo-1.2-0.dll -Wl,--enable-auto-image-base -Xlinker
--out-implib -Xlinker .libs/libfoo-1.2.dll.a
Creating library file: .libs/libfoo-1.2.dll.a
libtool: link: ar cru .libs/libfoo-1.2. sources.o
libtool: link: ranlib .libs/libfoo-1.2.
libtool: link: ( cd ".libs" && rm -f "libfoo-1.2.la" && ln -s
"../libfoo-1.2.la" "libfoo-1.2.la" )
In this specific case, the static library is missing the ".a" extension
(Windows ignores the final dot, as usual). Here's why:
This package had AM_GNU_GETTEXT in configure.ac without any arguments
nor AM_GNU_GETTEXT_VERSION. autoreconf decided "not using Gettext"
>  autoreconf decided "not using Gettext" because it looks solely for
> AM_GNU_GETTEXT_VERSION to make that determination. (It only looks for
> AM_GNU_GETTEXT to see if one of these two is used without the other,
> and emits a warning if so.)
Looks like a gettext bug to me. Might be fixed in 0.16+, but please
and didn't install config.rpath.
>  lib-link.m4 0.15 adds a line telling automake >= 1.10 that
> config.rpath is required, but this package was using 1.9. In
> any case, this macro was from 0.11.2, which preceded automake-1.10.
That's bizarre. Also, I believe that config.rpath may have a bug:
--- config.rpath 2008-04-16 03:59:54.875000000 -0400
+++ config.rpath 2008-04-16 04:00:04.546875000 -0400
@@ -501,7 +501,7 @@
cygwin* | mingw* | pw32*)
darwin* | rhapsody*)
because the result of config.rpath is used to probe /usr/lib, not
/usr/bin...BUT shrext is a widely used variable, and is not namespaced.
No telling WHAT that change might break, which is why I haven't
reported this as a "bug". But I did have to impose that patch in the
alternatives cygport, because otherwise I was forced to link statically
to libintl and libiconv.
Also, 'alternatives' is a wierd case -- I had to hack it to death since
it's not actually a package of its own; it's really 'chkconfig'. So I
decided not to draw any wide-ranging conclusions about config.rpath from
any issues involving the alternative package.
But AC_LIB_RPATH (from the included
gettext-0.11.2 lib-link.m4) was called; while nothing happened due to
the missing config.rpath, it then defined libext=$acl_cv_libext, which
had never been defined. This empty $libext clobbered that of libtool.
In this case, the solution was simply to call AM_GNU_GETTEXT_VERSION.
But this is the second case where libtool's had its variables clobbered
by other parts of configure. Could something be done to make sure that
that can't happen?
You don't want much, do you?
This is a apparently not a libtool-2.2 issue; if gettext is broken or
invoked incorrectly, AND shares some variables in the same namespace as
libtool, AND clobbers them...the only thing that can be done there is to
ensure that libtool never ever uses any variables outside the lt_ namespace.
There's been a lot of work done to try to make libtool namespace clean
and insensitive to variables outside lt_ -- but there's still quite a
bit to be done. One of the problems is the .la file format is fixed,
and the variables there are *not* in the lt_ namespace; there's no help
for that, except a format change.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html