Mail Archives: cygwin/2008/04/07/01:55:06
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/
- Raw text -