Mail Archives: cygwin/2008/04/08/03:59:57
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Charles Wilson wrote:
| 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.
I guess I'll be finding out exactly how many the hard way.
| 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...
I'm now looking at 2.2, what I mean is instead of (in libtool.m4):
AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT])
AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT])
Do something like the following:
AU_DEFUN([AC_PROG_LIBTOOL], [
LT_INIT
LT_OUTPUT
])
AU_DEFUN([AM_PROG_LIBTOOL], [
LT_INIT
LT_OUTPUT
])
AFAICS that would allow full compatibility with 1.5 behaviour after an
autoreconf. But I see now that this would cause LT_OUTPUT to be added
by autoupdate, which would generally be unnecessary. Is there another
way to do this?
| 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.
True, but I don't think that's the primary reason to have only one
libtool, and isn't the idea that it shouldn't be necessary to switch
back and forth?
| 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.
Time consuming, but fair enough. (I just ran a count, it's 1500 source
packages total, but it's hard to say how many of those use libtool.)
| 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.)
If the only real breakage is from LTDL API changes, then I agree it
should be quite rare.
| 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...
There is another case which might be tricky. Some packages (namely
Berkeley DB and KDE3) ship with libtool.m4 and then cat(1) it into
aclocal.m4 (BDB) or acinclude.m4 (KDE3). With 1.5, cygport simply
copies the libtool.m4 (and ltmain.sh) over the shipped copy in these cases.
With 2.2, besides the change in location (the /usr/share/libtool/config
subdir didn't exist in 1.5), there are now several libtool m4 macros.
Besides ltdl.m4 and argz.m4 (AFAICS required only by ltdl.m4), are they
all necessary for a working libtool.m4?
| 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).
Please do that ASAP so that I can make the necessary changes in cygport.
| So, "please remove the libtool1.5 dep from cygport. Full stop."
I don't see another choice for now, but if there becomes only one
libtool package, I would add it back.
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+yXTpiWmPGlmQSMRCDTdAKCs78ea+ZzeUPcU3WCRDfe+RtA01QCg4oeG
gV+hAZBVVa0dv6tuOtyIeV4=
=FjH/
-----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 -