Re: Libtool 2.2.2

Re: Libtool 2.2.2

[Angelo Graziosi]

Brian Dessent wrote:

 > Per the release announcement, it is incompatible with the libtool1.5
 > package, which means you have to manually deselect all other libtool
 > packages if you select libtool2.2.  You can only have one of the two
 > at any time installed

If this is the case, perhaps, there is some problem in setup.ini.

cygport requires libtool1.5 and libguile17 requires libltdl3.

So it looks that the set libtool1.5+libltdl3 cannot be removed in favor 
of libtool2.2+libltdl7 (if one needs cygport, libguile17+ dependences).

Cheers,
    Angelo.

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

Re: Libtool 2.2.2

[Brian Dessent]

Angelo Graziosi wrote:

> If this is the case, perhaps, there is some problem in setup.ini.
> 
> cygport requires libtool1.5 and libguile17 requires libltdl3.
> 
> So it looks that the set libtool1.5+libltdl3 cannot be removed in favor
> of libtool2.2+libltdl7 (if one needs cygport, libguile17+ dependences).

I may not have been clear.  The libltdl runtime packages should be fine
on their own, it's just the libtool developer packages that are
incompatible.  I don't think there should be a problem if you have
installed libltdl3+libltdl6+libltdl7+(one of libtool1.5 or libtool2.2). 
I'm not sure what libltdl6 is doing in the distro though as nothing
'requires:' it.

This shouldn't be too big of a problem as the libtool packages are only
needed if you relibtoolize something -- which you normally do not when
building from a tarball, only from a VCS checkout.  Though building any
cygport-ized package seems to force the issue since it likes to forcibly
"autoreconf -fvi".

Brian

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

Re: Libtool 2.2.2

[Angelo Graziosi]

Brian Dessent wrote:

> This shouldn't be too big of a problem as the libtool packages are
 > only needed if you relibtoolize something -- which you normally do not
 > when building from a tarball, only from a VCS checkout. Though
 > building any cygport-ized package seems to force the issue since it
 > likes to forcibly "autoreconf -fvi".

Perhaps I am missing something, but if you say

 > it is incompatible with the libtool1.5 package,
 > which means you have to manually deselect all other libtool packages
 > if you select libtool2.2

and if cygport depend on libtool1.5, how can the user who needs 
libtool2.2 install it without uninstalling libtool1.5+cygport+...?

If I try to uninstall libtool1.5, setup.exe says that cygport depend on 
it and stops the procedure at least one force it.

If one install libtool2.2 without removing anything, it overwrite 
libtool1.5, and I think this is a little confusing.

Suppose that an hypotetical user have not yet installed cygport and 
libtool* packages. Then this user install libtool2.2. Suppose now that 
the user needs also cygport: installing it, automatically libtool1.5 is 
chosen, overwriting libtool2.2! So the user thinks is using libtool2.2 
instead, since installing cygport, is using libtool1.5!

Cheers,
    Angelo.


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

Re: Libtool 2.2.2

[Brian Dessent]

Angelo Graziosi wrote:

> and if cygport depend on libtool1.5, how can the user who needs
> libtool2.2 install it without uninstalling libtool1.5+cygport+...?

They would have to manually override the warning of setup in order to
install libtool2.2+cygport.  

> If one install libtool2.2 without removing anything, it overwrite
> libtool1.5, and I think this is a little confusing.

Yes, it's not great but it's the best we can do.  Feel free to suggest
something less confusing, subject to the following constraints:

- Both libtools can't exist on a system at once
- Setup cannot express a mutual exclusivity, nor can it cause any
package to be deselected

The only thing I can think of is to wrap both libtool packages in a
postinstall wrapper (as is currently done with the gcc-mingw-* packages)
that first checks if the other is installed before unpacking anything. 
Then it could choose to either uninstall the other package, or decline
to install itself.  This is messy in that a) "cygcheck -c" / "cygcheck
-l" / "cygcheck -f" cease to work as expected for the package and b)
it's a lot more work to maintain such a package.  (a) could be worked
around by rewriting the manifest so that after the postinstall is run it
looks like a normal package.

> Suppose that an hypotetical user have not yet installed cygport and
> libtool* packages. Then this user install libtool2.2. Suppose now that
> the user needs also cygport: installing it, automatically libtool1.5 is
> chosen, overwriting libtool2.2! So the user thinks is using libtool2.2
> instead, since installing cygport, is using libtool1.5!

In the short term it would probably make more sense to simply drop
libtool from the cygport 'requires:' and instead document somewhere that
you need one or the other installed.  Cygport could potentially drop
something in profile.d to do this check and alert the user if
something's wrong, however I dislike the idea of penalizing every
cygport user with yet another task at the start of every login shell. 
It could also be possible for a cygport postinstall to check for libtool
and only if not found drop something in profile.d that displays a
warning.

Yet another option would be to fix setup to allow more complex
dependencies to be expressed, but that's even more complicated as a)
SHTDI and b) there's always going to be users not using the latest
setup.exe even months/years after a new version is released.

Brian

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

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

[Charles Wilson]

Brian Dessent wrote:
> Angelo Graziosi wrote:
> 
>> and if cygport depend on libtool1.5, how can the user who needs
>> libtool2.2 install it without uninstalling libtool1.5+cygport+...?

I think cygport should remove its requires: libtoolx.y from its 
setup.hint.  It currently lists that because the default
   src_compile()
implementation calls
   cygautoreconf()
which itself checks the to-be-built packages' configure.[in|ac] and 
checks that various autotools are installed. It doesn't do anything 
special with regards to libtool, except:

   if WANT_AUTOCONF=2.1
     if configure.[in|ac] contains "A[CM]_PROG_LIBTOOL"
       issue a warning that libtool1.5 is incompatible with autoconf-2.13

CYGPORT CODE CHANGE:
Now, with libtool2.2, that test needs to also check for LT_INIT, as well 
as the older A[CM]_PROG_LIBTOOL macros.  Furthermore, you can still use 
cygport even without libtoolx.y installed:

write your own src_compile() method that doesn't call cygautoreconf

"export LIBTOOL=no" before calling cygautoreconf (or "before" calling 
the default src_compile)

So, really, libtoolx.y is not a requirement of *cygport*, per se, but is 
a build-depends of whatever you are trying to use cygport to build.

> They would have to manually override the warning of setup in order to
> install libtool2.2+cygport.  
> 
>> If one install libtool2.2 without removing anything, it overwrite
>> libtool1.5, and I think this is a little confusing.

And will break things, as the OP pointed out.

> Yes, it's not great but it's the best we can do.  Feel free to suggest
> something less confusing, subject to the following constraints:
> 
> - Both libtools can't exist on a system at once
> - Setup cannot express a mutual exclusivity, nor can it cause any
> package to be deselected
> 
> The only thing I can think of is to wrap both libtool packages in a
> postinstall wrapper 

Ugh. No, thanks.

> In the short term it would probably make more sense to simply drop
> libtool from the cygport 'requires:' and instead document somewhere that
> you need one or the other installed.

But you don't, really. See above.

> Cygport could potentially drop
> something in profile.d to do this check and alert the user if
> something's wrong, however I dislike the idea of penalizing every
> cygport user with yet another task at the start of every login shell. 

CYGPORT CODE CHANGE:
No, instead cygport itself, inside cygautoreconf(), could perform that 
check.  That is, if LIBTOOL != "no", and configure.[ac|in] contains 
LT_INIT|A[CM]_PROG_LIBTOOL, then
   if ! check_prog libtool1.5 && !check_prog libtool2.2
     issue error message about missing libtool

> It could also be possible for a cygport postinstall to check for libtool
> and only if not found drop something in profile.d that displays a
> warning.

No need to mess with profile.d; cygport itself can do the check. That 
way, only cygport users, when actually using cygport, are "penalized" by 
checking for libtool presence.

> Yet another option would be to fix setup to allow more complex
> dependencies to be expressed, but that's even more complicated as a)
> SHTDI and b) there's always going to be users not using the latest
> setup.exe even months/years after a new version is released.

Yep, to both.

In any case, there is no need to wait for the various modifications to 
cygport. We can (and should) remove the libtool1.5 require: from 
cygport's setup.hint immediately. (Where "immediately" means "give 
Yaakov a decent interval to chime in on this thread...")

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

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

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chuck,

I have yet to try libtool 2.2, but I'm sure that you have thoroughly
tested it.  Could you clarify a few things:

*) 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?  If it's
not, it should be, as I know of a number of packages which rely on the
libtool script during configure.

*) Is running autoupdate recommended or beneficial when building a
package using 1.5?

*) If 2.2 is backwards compatible with 1.5, but they can't be installed
in parallel, why not just rename all versions of the package to "libtool"?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+aEUpiWmPGlmQSMRCNzZAKCwVUZSnCfNT40qbcKMmSZk+YG8yQCgkBH6
MaRdX7OWU/E8oxNtBwYJMhs=
=Jk2A
-----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/

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

[Charles Wilson]

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/

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

[Yaakov (Cygwin Ports)]

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

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

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> | That should be taken up with the libtool maintainers.  However, it has
[snip]
> 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
> WILL break. 

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
> with 1.5?

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.

Ack.

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 
/explicit/path/to/libtool2.2.info'.

> 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 
private email...)

==== 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"
> | paradigm, 
>
> I don't want to go there again either.

Okay. We're agreed. <g>

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

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."

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

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

[Yaakov (Cygwin Ports)]

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

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

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> 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.

I'm not so sure. I still think that calling LT_OUTPUT immediately after 
LT_INIT is not exactly equivalent to 1.5 behavior. I think that is too 
early...but I don't know how to force a non-local insertion of 
LT_OUTPUT, and even if I did, I don't know how "far down" in 
configure.ac that non-local insertion should go.

Of course, if you KNOW of a package that needs libtool before configure 
is finished (I don't), you could easily test my assertion by manually 
inserting LT_OUTPUT immediately after A[CM]_PROG_LIBTOOL/LT_INIT, 
manually running autoreconf with libtool2.2, and see if it works...

But even so, this means that as part of cygport [*] you'd need to run 
autoupdate, which is not the current behavior.

[*] But again, my recommedation is that cygport should NOT run 
autoupdate in an automated way. Instead, the package maintainer should 
run it, inspect the results, and fold those changes into .src.patch.  In 
which case, manually adding LT_OUTPUT before generating .src.patch only 
when necessary rather than relying on autoupdate to do it automatically 
always even when unecessary, seems to be the better way to go.

>  But I see now that this would cause LT_OUTPUT to be added
> by autoupdate, which would generally be unnecessary. 

That's a drawback, all right.

> Is there another
> way to do this?

I don't know.

> 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?

Well, yeah -- in a perfect world.

> | 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?

Correct. The gcc folks ran into this. FWICT, you need each of: 
libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4, lt-obsolete.m4,

It is recommeded, instead of copying those contents into aclocal.m4, 
that instead you do:

m4_include([libtool.m4])
m4_include([ltoptions.m4])
m4_include([ltversion.m4])
m4_include([ltsugar.m4])
m4_include([lt~obsolete.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.

Sure...just waiting for more input.

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

I have modified cygport's setup.hint on sources.

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

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

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
| I'm not so sure. I still think that calling LT_OUTPUT immediately after
| LT_INIT is not exactly equivalent to 1.5 behavior. I think that is too
| early...but I don't know how to force a non-local insertion of
| LT_OUTPUT, and even if I did, I don't know how "far down" in
| configure.ac that non-local insertion should go.

I think it is equivalent, seeing from a typical configure run with
libtool 1.5:

...
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
...
appending configuration tag "F77" to libtool
...

| Of course, if you KNOW of a package that needs libtool before configure
| is finished (I don't), you could easily test my assertion by manually
| inserting LT_OUTPUT immediately after A[CM]_PROG_LIBTOOL/LT_INIT,
| manually running autoreconf with libtool2.2, and see if it works...

Some GNOME autoconf-based packages with python support run a
python-module compile and link test with the previously created libtool.

| That's a drawback, all right.

Looking at some of the other compatibility macros, how about the
following instead:

AU_DEFUN([AC_PROG_LIBTOOL],
[LT_INIT
LT_OUTPUT
AC_DIAGNOSE([obsolete],
[$0: Remove this warning and the call to LT_OUTPUT if you do not need
libtool to exist before AC_OUTPUT.])
])

AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])

| But even so, this means that as part of cygport [*] you'd need to run
| autoupdate, which is not the current behavior.
|
| [*] But again, my recommedation is that cygport should NOT run
| autoupdate in an automated way. Instead, the package maintainer should
| run it, inspect the results, and fold those changes into .src.patch.  In
| which case, manually adding LT_OUTPUT before generating .src.patch only
| when necessary rather than relying on autoupdate to do it automatically
| always even when unecessary, seems to be the better way to go.

Agreed.

| Correct. The gcc folks ran into this. FWICT, you need each of:
| libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4, lt-obsolete.m4,
|
| It is recommeded, instead of copying those contents into aclocal.m4,
| that instead you do:
|
| m4_include([libtool.m4])
| m4_include([ltoptions.m4])
| m4_include([ltversion.m4])
| m4_include([ltsugar.m4])
| m4_include([lt~obsolete.m4])

While that makes sense, I doubt that would work with the special build
systems that I'm discussing, at least not in an automated way without
patching those build systems more than necessary.  I have something else
in mind, but I'll need to try it out first.

| Sure...just waiting for more input.

Could you post the answer on cygwin-apps?

| I have modified cygport's setup.hint on sources.

Thank you.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+/aMpiWmPGlmQSMRCLeqAJ42Na5Iyxr2C3Bzs7vnuVWinav3uQCgxWgw
K4mhjGWMeBAM1R92B3LsJQU=
=FHgr
-----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/

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

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> | I'm not so sure. I still think that calling LT_OUTPUT immediately after
> | LT_INIT is not exactly equivalent to 1.5 behavior.
> 
> I think it is equivalent, seeing from a typical configure run with
> libtool 1.5:
> 
> Looking at some of the other compatibility macros, how about the
> following instead:
> 
> AU_DEFUN([AC_PROG_LIBTOOL],
> [LT_INIT
> LT_OUTPUT
> AC_DIAGNOSE([obsolete],
> [$0: Remove this warning and the call to LT_OUTPUT if you do not need
> libtool to exist before AC_OUTPUT.])
> ])
> 
> AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])

That looks OK to me. I'll include something like this in the next 
version of libtool2.2 (or "libtool" test: 2.2).

> | [*] But again, my recommedation is that cygport should NOT run
> | autoupdate in an automated way. Instead, the package maintainer should
> | run it, inspect the results, and fold those changes into .src.patch.
> 
> Agreed.
> 
> | m4_include([libtool.m4])
> | m4_include([ltoptions.m4])
> | m4_include([ltversion.m4])
> | m4_include([ltsugar.m4])
> | m4_include([lt~obsolete.m4])
> 
> While that makes sense, I doubt that would work with the special build
> systems that I'm discussing, at least not in an automated way without
> patching those build systems more than necessary.  I have something else
> in mind, but I'll need to try it out first.

For your packages, do whatever makes your life easier. <g>

> | Sure...just waiting for more input.
> 
> Could you post the answer on cygwin-apps?

Sure.

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

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

[Yaakov (Cygwin Ports)]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
| Yaakov (Cygwin Ports) wrote:
|> AU_DEFUN([AC_PROG_LIBTOOL],
|> [LT_INIT
|> LT_OUTPUT
|> AC_DIAGNOSE([obsolete],
|> [$0: Remove this warning and the call to LT_OUTPUT if you do not need
|> libtool to exist before AC_OUTPUT.])
|> ])
|>
|> AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])
|
| That looks OK to me. I'll include something like this in the next
| version of libtool2.2 (or "libtool" test: 2.2).

One more patch will be required, namely, to define OBJDUMP where
necessary.  I've rolled these two patches together, as attached.

Explanation:

The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which
built on Win32 platforms, in order to create DLLs.  This macro tested
for as, dlltool, and objdump.  The latter is used in the file_magic test
to determine if a .a is a static or import library.

In 1.5 libtool worked anyway without it, because among other variables,
OBJDUMP was given a "sane default" near the beginning of libtool.m4 and
was always exported, and AS and DLLTOOL weren't needed.

But in 2.2, the "sane defaults" have been minimized, and OBJDUMP is no
longer defined by default, so without the win32-dll arg to LT_INIT (or
the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared
libs against non-libtoolized shared libs, because the file_magic test on
the implib fails due to an undefined OBJDUMP variable.  Assuring that
OBJDUMP is defined is therefore necessary for compatibility with
previous behaviour.

Not only that, but this may fix another possible bug on Linux ELF
systems, as there is a test on that platform (line 2461 after the patch)
which uses OBJDUMP, which I don't see where it would have been defined.



Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIAeHppiWmPGlmQSMRCLo1AKDx1ENwmwMhmKvL12avJ1RuVJfBHACg2g69
NKjvebLP38bbNdqP/cis8GI=
=Z4Tf
-----END PGP SIGNATURE-----

[-- Attachment #2: libtool-cygwin.diff --]
[-- Type: text/plain, Size: 1664 bytes --]

--- libltdl/m4/libtool.m4	2008-04-01 13:20:04.000000000 -0500
+++ /usr/share/aclocal/libtool.m4	2008-04-13 05:21:22.296875000 -0500
@@ -99,8 +99,15 @@
 ])# LT_INIT
 
 # Old names:
-AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT])
-AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT])
+AU_DEFUN([AC_PROG_LIBTOOL],
+[LT_INIT
+LT_OUTPUT
+AC_DIAGNOSE([obsolete],
+[$0: Remove this warning and the call to LT_OUTPUT if you do not need
+libtool to exist before AC_OUTPUT.])
+])
+
+AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])
 dnl aclocal-1.4 backwards compatibility:
 dnl AC_DEFUN([AC_PROG_LIBTOOL], [])
 dnl AC_DEFUN([AM_PROG_LIBTOOL], [])
@@ -2026,6 +2033,7 @@
 [AC_REQUIRE([AC_CANONICAL_HOST])dnl
 m4_require([_LT_DECL_EGREP])dnl
 m4_require([_LT_FILEUTILS_DEFAULTS])dnl
+m4_require([_LT_DECL_OBJDUMP])dnl
 m4_require([_LT_DECL_SED])dnl
 AC_MSG_CHECKING([dynamic linker characteristics])
 m4_if([$1],
@@ -2947,6 +2955,7 @@
 #  -- PORTME fill in with the dynamic library characteristics
 m4_defun([_LT_CHECK_MAGIC_METHOD],
 [m4_require([_LT_DECL_EGREP])
+m4_require([_LT_DECL_OBJDUMP])
 AC_CACHE_CHECK([how to recognize dependent libraries],
 lt_cv_deplibs_check_method,
 [lt_cv_file_magic_cmd='$MAGIC_CMD'
@@ -6961,6 +6970,18 @@
 ])
 
 
+# _LT_DECL_OBJDUMP
+# --------------
+# If we don't have a new enough Autoconf to choose the best objdump
+# available, choose the one first in the user's PATH.
+m4_defun([_LT_DECL_OBJDUMP],
+[AC_CHECK_TOOL(OBJDUMP, objdump, false)
+test -z "$OBJDUMP" && OBJDUMP=objdump
+_LT_DECL([], [OBJDUMP], [1], [An object symbol dumper])
+AC_SUBST([OBJDUMP])
+])
+
+
 # _LT_DECL_SED
 # ------------
 # Check for a fully-functional sed program, that truncates


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

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

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:
> One more patch will be required, namely, to define OBJDUMP where
> necessary.  I've rolled these two patches together, as attached.
> 
> Explanation:
> 
> The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which
> built on Win32 platforms, in order to create DLLs.  This macro tested
> for as, dlltool, and objdump.  The latter is used in the file_magic test
> to determine if a .a is a static or import library.
> 
> In 1.5 libtool worked anyway without it, because among other variables,
> OBJDUMP was given a "sane default" near the beginning of libtool.m4 and
> was always exported, and AS and DLLTOOL weren't needed.
 >
> But in 2.2, the "sane defaults" have been minimized, and OBJDUMP is no
> longer defined by default,

I believe this was an attempt at optimization: avoid testing for 
specific tools need only on one platform, unless libtool has been told 
that it is ON that platform.  Oddly, you'd think that libtool would 
figure that out from $build/$host/$target, and not [win32-dll].

> so without the win32-dll arg to LT_INIT (or
> the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared
> libs against non-libtoolized shared libs, because the file_magic test on
> the implib fails due to an undefined OBJDUMP variable.  Assuring that
> OBJDUMP is defined is therefore necessary for compatibility with
> previous behaviour.
> 
> Not only that, but this may fix another possible bug on Linux ELF
> systems, as there is a test on that platform (line 2461 after the patch)
> which uses OBJDUMP, which I don't see where it would have been defined.

Which is also odd.  I wonder why linux uses objdump...maybe this is a 
dead code path?

Oh, well: if it's necessary, it's necessary, and I'll push it upstream 
as well as including it in my next release of libtool2.2 (or "libtool" [*]).

Thanks for doing this, Yaakov.

-- 
Chuck

[*] Having heard no objections, and a few votes in favor, I'm leaning 
towards replacing both libtool1.5 and libtool2.2 with a single "libtool" 
package, with 1.5-derived versions remaining "curr:" for the near-term. 
In the medium term, I expect that prev: will be the latest-1.5 
derivative, and curr:/test: will both be 2.2-derived.  Long term, 
libtool-1.5 will disappear from the standard prev:/curr:/test: trio, but 
setup's chooser should still allow the determined user to find a 1.5 
variant if they click enough.

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

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

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
| I believe this was an attempt at optimization: avoid testing for
| specific tools need only on one platform, unless libtool has been told
| that it is ON that platform.  Oddly, you'd think that libtool would
| figure that out from $build/$host/$target, and not [win32-dll].

More than that, is AC_LIBTOOL_WIN32_DLL (now [win32-dll]) actually
necessary anymore?  Cygwin doesn't need it, but I don't know about MinGW.

| Which is also odd.  I wonder why linux uses objdump...maybe this is a
| dead code path?

I'm not sure; AFAICS such a test didn't exist for linux in libtool 1.5.

| [*] Having heard no objections, and a few votes in favor, I'm leaning
| towards replacing both libtool1.5 and libtool2.2 with a single
| "libtool" package, with 1.5-derived versions remaining "curr:" for the
| near-term.

With my patch to libtool and some tweaking of cygport, libtool 2.2 seems
to be working pretty well.  I will need to know your final decision
before committing the cygport patches, and I'll try to push an update as
soon as possible thereafter.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIAtMzpiWmPGlmQSMRCE3eAJ9mQXitBbfqWUnLRFL7HmalQaG2fgCeLd/A
yA/G/Orc2yZcwB7GVikWUI4=
=N1Er
-----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/