Message-ID: <47F9B6B6.4090908@cwilson.fastmail.fm>
Date: Mon, 07 Apr 2008 01:52:54 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
References: <47F6A816 DOT 2010208 AT alice DOT it> <47F73BA6 DOT 6000001 AT alice DOT it> <47F7E1D1 DOT 804DF919 AT dessent DOT net> <47F94F88 DOT 6050705 AT cwilson DOT fastmail DOT fm> <47F9A114 DOT 3060608 AT users DOT sourceforge DOT net>
In-Reply-To: <47F9A114.3060608@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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/