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
- From: "Yaakov (Cygwin Ports)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin at cygwin dot com
- Date: Tue, 06 May 2008 00:11:51 -0500
- Subject: Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
- References: <firstname.lastname@example.org> <48110B6B.email@example.com>
-----BEGIN PGP SIGNED MESSAGE-----
Yaakov (Cygwin Ports) wrote:
| This package had AM_GNU_GETTEXT in configure.ac without any arguments
| nor AM_GNU_GETTEXT_VERSION. autoreconf decided "not using Gettext"
| and didn't install config.rpath. 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.
This is worse than I originally thought. AM_ICONV also calls AC_LIB_RPATH.
I got yet another broken libtool, this time with a "unsupported hardcode
properties" error. Here's why: a different package shipped with a
0-byte config.rpath, which obviously didn't do much. But the real
problem is with AC_LIB_RPATH itself. In 0.15, it defines the following:
Except for shlibext, all of the above variables can conflict with
variables by the same name in libtool. If the config.rpath call doesn't
succeed (usually because it's nonexistant), all of these variables are
blank, which then clobbers the variables previously set by libtool.
While each of these cases should be fixed within the package, I think
the only *safe* answer is that:
1) libtool MUST protect its variables;
2) AC_LIB_RPATH should check that there was actually a result from
config.rpath before proceeding.
(And I would still patch shrext=dll.a as you suggested.)
One thing I don't understand: if you call LT_OUTPUT (which generates an
unclobbered libtool), isn't 'config.status libtool' supposed to use
config.lt to generate libtool, which should avoid these problems?
|  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.
Lots of good that did me here, as the file was present but blank. :-(
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html