Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

["Yaakov (Cygwin Ports)" <yselkowitz at users dot sourceforge dot net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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"[1]
| and didn't install config.rpath[2].  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:

wl="$acl_cv_wl"
libext="$acl_cv_libext"
shlibext="$acl_cv_shlibext"
hardcode_libdir_flag_spec="$acl_cv_hardcode_libdir_flag_spec"
hardcode_libdir_separator="$acl_cv_hardcode_libdir_separator"
hardcode_direct="$acl_cv_hardcode_direct"
hardcode_minus_L="$acl_cv_hardcode_minus_L"

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?

| [2] 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. :-(


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgf6JcACgkQpiWmPGlmQSMolwCgiEIu5ZMjD1dulA+6uix60pTm
2j0An3ogNN7lFh0Sw8rvtmwJFrOtWO+I
=DHry
-----END PGP SIGNATURE-----

--
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/