bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))


From: Gary V. Vaughan
Subject: bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))
Date: Mon, 22 Dec 2014 21:22:01 +0000

tags 19370 notabug
close 19730

Hi Jeff,

Sorry for the delay.

On Dec 20, 2014, at 11:18 AM, Jeff Squyres (jsquyres) <address@hidden> wrote:
> 
> Thanks for replying, Gary. 

Even though I didn't read the original report carefully enough...

> I did include what analysis I was able to do in my first email: I tracked 
> down that the problem is that the "make" rules decide to invoke aclocal in 
> the embedded libltdl because it's looking for non-existent files as 
> dependencies (it looks like the wrong path is being used somehow?).

...because you'd already included pretty much everything I asked for.

> I didn't go beyond that - I don't know the internals of libtool (this is a 
> regression compared to 2.4.2). 
> 
> I also included a reproducer, both as a tarball and as a link to a github 
> repo. 

Perfect!  So, even though your tarball does reproduce the bug you describe, I 
first converted it to a new autotest to protect against future reappearance of 
the bug, only to discover that inside the testsuite everything works as it 
should.  Hmm.

> Hopefully that's enough to get you going in the right direction. 

Indeed it is.  And the problem is that autoreconf, as called from the 
autogen.sh in the tarball, still runs the tools in the wrong order.  Autoreconf 
stupidly runs aclocal first, and then calls libtoolize which adds more m4 files 
to AC_CONFIG_MACRO_DIR, and that in turn causes aclocal.m4 to be out of date 
(because it needs to be regenerated to pick up the local versions of the 
libtoolize added m4 files added to ../config/ after it was first generated).

The bootstrap script in the libtool source tree fixes this (and many other 
problems with the autogen.sh/autoreconf approach), so if you care to write a 
bootstrap.conf (by copying and hacking nearly everything out of 
libtool-2.4.4/bootstrap.conf), things are then created in the right order and 
the bug disappears.

Alternatively, you can amend your autogen.sh to something like this:

  libtoolize --install --copy --ltdl
  LIBTOOLIZE=true autoreconf -fvi

If it worked for you in 2.4.2 in that order, then it was just a lucky 
combination of an empty local directory and installed versions of the macro 
files in the right place for aclocal.m4 to be valid on the initial too-early 
run.

In your original report, however, you said:

"The problem appears to be that make is checking for ../m4/libtool.m4 file as a 
dependency.  This file file -- and the entire ../m4 directory, for that matter 
-- does not exist.  So make decides to fire the "run the aclocal" rule."

...which seems odd to me, because for a subproject libltdl, the parent 
AC_CONFIG_MACRO_DIR/ACLOCAL_AMFLAGS directory is supposed to be merged in.  Did 
you mean to say "../config/libtool.m4" above?  If that substitution really 
isn't happening, then you've found a different bug - but I can't reproduce that 
one with 2.4.3, 2.4.4 nor current master.

HTH,
-- 
Gary V. Vaughan (gary AT vaughan DOT pe)

> Sent from my phone. No type good. 
> 
>> On Dec 19, 2014, at 3:19 PM, Gary V. Vaughan <address@hidden> wrote:
>> 
>> Hi Jeff,
>> 
>> I'm sorry, I didn't yet have chance to work on this... I'll try to reproduce 
>> it over the holidays,
>> and depending on whether that makes it obvious what's happening, a fix may 
>> or not be
>> straight forward and forthcoming.
>> 
>> It would certainly speed things along if you could help produce an analysis, 
>> a small self
>> contained reproducer, a test case and/or propose a patch.
>> 
>> Sorry I can't be of more help for the moment,
>> -- 
>> Gary V. Vaughan (gary AT vaughan DOT pe)
>> 
>>> On 19 Dec 2014, at 20:03, Jeff Squyres (jsquyres) <address@hidden> wrote:
>>> 
>>> Any comments on this, perchance?
>>> 
>>> It's a blocker for us in the Open MPI project; it prevents us from 
>>> upgrading from 2.4.2.
>>> 
>>> It's a bit of a problem because some software projects, such as mac-ports 
>>> and home-brew are shipping LT >= 2.4.3.
>>> 
>>> 
>>>> On Dec 13, 2014, at 1:01 PM, GNU bug Tracking System <address@hidden> 
>>>> wrote:
>>>> 
>>>> Thank you for filing a new bug report with debbugs.gnu.org.
>>>> 
>>>> This is an automatically generated reply to let you know your message
>>>> has been received.
>>>> 
>>>> Your message is being forwarded to the package maintainers and other
>>>> interested parties for their attention; they will reply in due course.
>>>> 
>>>> Your message has been sent to the package maintainer(s):
>>>> address@hidden
>>>> 
>>>> If you wish to submit further information on this problem, please
>>>> send it to address@hidden
>>>> 
>>>> Please do not send mail to address@hidden unless you wish
>>>> to report a problem with the Bug-tracking system.
>>>> 
>>>> -- 
>>>> 19370: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19370
>>>> GNU Bug Tracking System
>>>> Contact address@hidden with problems
>>> 
>>> 
>>> -- 
>>> Jeff Squyres
>>> address@hidden
>>> For corporate legal information go to: 
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Bug-libtool mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/bug-libtool
> 
> 
> 
> _______________________________________________
> Bug-libtool mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-libtool






reply via email to

[Prev in Thread] Current Thread [Next in Thread]