Mail Archives: cygwin/2008/04/07/09:45:16
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Charles Wilson wrote:
| 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).
If I need to add LT_OUTPUT already, then I might as well switch entirely
to the LT_* macros. The compatibility AC_PROG_LIBTOOL macro should be
just that: compatible with previous behaviour; otherwise, old packages
WILL break. This should not affect LT_INIT and the intended behaviour
for the future.
~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
with 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.
OK, that makes sense.
| 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.
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.
| 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.
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?
| 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.
I agree completely.
| 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.
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.
| I see a lot of "uninstall-libtool1.5/install-libtool2.2"
| "uninstall-libtool2.2/install-libtool1.5" cycles in our future.
That's really too much trouble for those of us with hundreds (or
thousands) of packages.
| 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.
That's also pretty complicated. When would a package NOT work with 2.2?
| 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.
I don't want to go there again either.
To summarize:
*) 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.
*) 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.
*) 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.
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+iVLpiWmPGlmQSMRCD5VAJ9VDKLK+4/jSZx32z8O9FOW6/aekwCgsnIy
1bZxrowSELR2MVJAJ9vJHTU=
=VURg
-----END PGP SIGNATURE-----
--
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 -