This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]

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:

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

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]