This is the mail archive of the
mailing list for the Cygwin project.
Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote:
Charles Wilson wrote:
| That should be taken up with the libtool maintainers. However, it has
If I need to add LT_OUTPUT already, then I might as well switch entirely
to the LT_* macros.
True. But that is NOT required. libtool-emit-time is simply a new
(possible backwards-incompatible) behavior change of the new libtool --
but one that hopefully impacts few clients.
The compatibility AC_PROG_LIBTOOL macro should be
just that: compatible with previous behaviour; otherwise, old packages
A very very small number. The attitude of the libtool maintainers is,
this extremely small minority is supported via the LT_OUTPUT macro. For
everybody else, the vast majority, AC_PROG_LIBTOOL will Just Work(tm),
and we (they) are not going to pessimize everybody else just to support
that small minority -- who can use the LT_OUTPUT if they really need to.
This should not affect LT_INIT and the intended behaviour
for the future.
The change with regards to when, during the configure process, the
libtool script itself is generated, is a separate and orthogonal issue
from "did you use the old A[CM]_PROG_LIBTOOL macro or the LT_INIT
macro". Rather, the libtool-emit-time change is (one of the few)
backwards-incompatiblities. Using the new libtool? Then the /default/
libtool-emit behavior has changed; simple as that.
~From the way you put it, it sounds like I shouldn't even waste my time
asking upstream. If they won't accept this, can our libtool package be
patched accordingly, so that packages work after libtoolize as they did
Anything CAN be done, with enough developer 'tuits. The question is, is
that wise? I don't know where to *automatically* insert a call to
LT_OUTPUT in Q_RANDOM_PACKAGE's configure.ac; and I can't simply revert
to "the old way"-- because the libtool-emission mechanisms are vastly
different from 1.5.x. You don't know what you're asking...
| You can continue to use
| AC_PROG_LIBTOOL exactly as you did with libtool1.5.
OK, that makes sense.
I'm not sure exactly how widely tested 2.2 is, so I understand the
logic. But there are a few packages with some 2.x libtool included
(ImageMagick comes to mind), for which 1.5 is useless, and I don't want
to wait too long to switch.
And Bob F. jumped to 2.2 prematurely, IMO...
I was looking more at the autoconf/automake side of libtool, but you
raise a good point. Where are the ltdl changes outlined, and how many
packages break due to those changes?
Most of the removed interfaces were removed *because* they were not
widely used (and were ugly; couldn't support the new features, etc). The
changes are detailed in the new libtool's .info files. You can view them
"offline" by unpacking libtool2.2 somewhere "safe" and using 'info -f
If AC_PROG_LIBTOOL can be compatible, and the ltdl API changes are
indeed minor, than libtool should be a single package, especially if
they can't be installed in parallel (unlike ac/am). It may be helpful
for 2.2 to be in testing for a little while.
Well, that's one of the possibilities I raised in my other
email...however, it really doesn't solve the problem. It just makes
switching between 1.5 and 2.2 a little easier given our setup.exe.
Instead of explicitly uninstalling 2.2 and installing 1.5 (or vice
versa), you just change the version of the single 'libtool' package from
1.5 to 2.2 (or vice versa) -- which effectively does the same thing:
uninstall one then install the other.
That's really too much trouble for those of us with hundreds (or
thousands) of packages.
Well, according to Ralf (hope he doesn't mind my paraphrase of his
==== start Ralf ====
LT_OUTPUT: I do not know how many packages are impacted by the LT_OUTPUT
incompatibility issue, but was so far of the impression that it would be
rather few. If that impression is wrong, then it's certainly a good
idea to let libtool at gnu dot org know about this.
LTDL API CHANGES: clients just need to cope. If there are clients out
there for which it would be an unduly amount of work or hassle, we'd
like to know about it. Actually, even more than with LT_OUTPUT, I
believe that problems should be far and few between here.
==== end Ralf ====
The remainder of Ralf's email would tend to support this portion of your
position: consolidate to a single 'libtool' package, make 2.2 the 'test'
version, and leave it there until most of the maintainers have had a
chance to see what issues arise with their packages. Then, and only
then, bump the 2.2 version to current.
His suggestion was: hey, just install libtool2.2 and rip through all
your packages (...er, all 1300 of them? ...) and most of them ought to
be fine. If more than a handful are not, then we (the libtool devs)
need to know.
| But this sort of thing is only necessary for those (hopefully rare)
| packages where it actually MATTERS which version of libtool you use.
That's also pretty complicated. When would a package NOT work with 2.2?
Yes it is. The problems would occur if the client needed a lot of work
to come into compliance with the new LTDL API. The LT_OUTPUT thing is
really very easy to fix for a given package. (And, according to Ralf,
the LT_OUTPUT thing, while rarely needed, is much more probable to arise
than LTDL API issues. That's good. I like my more common problems to
be easy to fix. And I like ALL my problems to be rare. Like my steak.)
| Even so, I hate to go back to the old "libtool-stable/libtool-devel"
I don't want to go there again either.
Okay. We're agreed. <g>
*) AC_PROG_LIBTOOL 2.2 should be fully compatible with 1.5 by calling
LT_OUTPUT. Patching libtool in this way will save all of us patching
more packages in the future.
But it is not that simple. The "old" way of generating/emitting libtool
was not simply "call some LT_OUTPUT-like macro at the "end" of
AC_PROG_LIBTOOL"; that's far too early. And in almost all cases,
waiting until AC_OUTPUT() is fine.
Besides, libtool-2.2 compatibility patches are the sort of thing
upstream maintainers like to see...
*) 1.5 and 2.2 aren't parallel-installable, nor should we imagine they
will be in the near future. In that case, there should be only one
libtool package, with 2.2 in testing for now, and maintainers strongly
encouraged to test.
Well, Ralf seems to agree. I'd like to hear from a few other
maintainers before taking that plunge though. (For now, just don't
install the "new" libtool2.2 package, and you'll be fine).
*) In the meantime, please remove the libtool1.5 dep from cygport, as
long as one of the libtools are pulled in by autoconf or automake.
Well, no -- autoconf doesn't need libtool, and neither does automake. My
point in the earlier email was that cygport *itself* doesn't really need
libtool either. libtool *may* be a build-depends of some other package
that you USE cygport to build, but with an appropriately coded .cygport
you can use cygport without libtool at all.
Thus, libtool is not required: by cygport, it is merely optional and
highly recommended. That way, cygport doesn't need to specify exactly
which VERISON of libtool is recommended. :-)
So, "please remove the libtool1.5 dep from cygport. Full stop."
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html