Yaakov (Cygwin Ports) wrote:
*) Most packages still use a 1.5 libtool, if not older. Is LT_OUTPUT
the default if the old-style AC_PROG_LIBTOOL macro is called?
No, it is not.
If it's
not, it should be, as I know of a number of packages which rely on the
libtool script during configure.
That should be taken up with the libtool maintainers. However, it has
been their position, even in the libtool-1.4 and -1.5 days, that relying
on that behavior was not recommended. Therefore they do not support it
"directly" -- but instead provided the LT_OUTPUT macro for those
packages that insist on ignoring their recommendations, or have really
good reasons for doing so (such as running AC_COMPILE tests that need
libtool).
*) Is running autoupdate recommended or beneficial when building a
package using 1.5?
IMO, no. autoupdate is not something that should be blindly done in an
automated fashion, because you really should verify the results
manually. I would recommend that, at least for now, maintainers
approach it on a case-by-case basis -- but remember, except for this
LT_OUTPUT thing (which can be added using foo-*.src.patch) you don't
HAVE to use the new libtool2.2 interfaces; you don't HAVE to use
autoupdate in order to use libtool2.2. You can continue to use
AC_PROG_LIBTOOL exactly as you did with libtool1.5.
For folks like you and Dr. Zell who maintain a LOT of packages, I'd
recommend keeping libtool1.5 installed for a while. Let the rest of us
with fewer packages deal with any possible libtool2.2 ripple.
For instance, if I wanted to try to use libtool2.2 on a particular
package, I might MANUALLY use autoupdate -- and then fold the (verified)
results into my .src.patch. I'd leave src_compile() and cygautoreconf
as-is.
*) If 2.2 is backwards compatible with 1.5,
It's MOSTLY backwards compatible, with (AFAIK) the following exceptions:
1) the LT_OUTPUT thing
2) the libltdl library has had a few API changes -- some functions
have been removed, others added. If your client uses those eliminated
APIs, then you'll have to make actual code changes to use the libltdl
from libtool-2.2.
As much as the libtool developers tried to maintain complete backwards
compatibility, this IS a major new release and reflects over four years
of development. It's impressive that the incompatibilities were kept as
minor as they are.
but they can't be installed
in parallel, why not just rename all versions of the package to "libtool"?
Well, I addressed this in another post, but nobody responded. It's here:
http://www.cygwin.com/ml/cygwin-apps/2008-04/msg00050.html
The FOSS community went thru this whole issue back during the
autoconf-2.13 to autoconf-2.5x transition. For a long time, you could
only have one or the other installed, until the distributions started
including wrapper scripts and installing both tools into different
locations/with different program names. (I believe cygwin was actually
the first to do this).
Unfortunately, I think we are in for a certain amount of turbulence,
just like back then. However, ac-2.5 and ac-2.13 were REALLY
incompatible. The changes here are much less visible; most packages
should be able to use either version of libtool with no *required*
changes. Any autoupdate/code changes/configure.ac changes will be
kinda-nice-but-not-really-necessary for most clients.
So for any particular client this transition is not a big deal. The real
problem is that any particular developer -- or cygwin package maintainer
-- probably works with a number of separate libtool client packages. And
not all of those are going to "transition" at the same time; nor is any
developer (cygwin package maintainer) going to want to brute force a
transition for all of his packages all at the same time.
I see a lot of "uninstall-libtool1.5/install-libtool2.2"
"uninstall-libtool2.2/install-libtool1.5" cycles in our future.
=========
I haven't done any investigation along these lines, but for some of us
cygwin package maintainers, we might think about self-compiling
/opt/libtool-2.2/{bin|share|lib} and /opt/libtool-1.5/{bin|share|lib}
[*], uninstalling BOTH libtool1.5 and libtool2.2, and using
/usr/share/aclocal/dirlist and $PATH to "switch" between them (dirlist
entries go AFTER the compiled-in -acdir paths used by aclocal, so you
have to uninstall the "normal" libtool packages make sure libtool.m4 and
friends won't be found in /usr/share/aclocal/)
Alternatively, you can keep the "normal" libtool package installed, but
instead patch client Makefile.am's to add ACLOCAL_AMFLAGS with
-I/opt/libtool-2.2/share/aclocal or -I/opt/libtool-1.5/share/aclocal AND
using $PATH (this works because -I paths go BEFORE the compiled-in
-acdir paths used by aclocal)
But this sort of thing is only necessary for those (hopefully rare)
packages where it actually MATTERS which version of libtool you use.
Even so, I hate to go back to the old "libtool-stable/libtool-devel"
paradigm, but during this transition we -- cygwin package maintainers --
might need to do so 'unofficially'. However, this is a lot of trouble,
and "uninstall-libtool1.5/install-libtool2.2"
"uninstall-libtool2.2/install-libtool1.5" cycles may actually be less
effort -- again, for those (hopefully rare) packages where using the
"wrong" libtool causes a problem.
[*] Similarly, I have
gcc-tools-autoconf-2.59-1
gcc-tools-automake-1.9.6-1
on my machine, which I compiled into /opt/{bin|share|lib} in order to
use with gcc development, because those are the mandated versions for gcc...
--
Chuck
--
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/
