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

From: "Gary V. Vaughan" <[email-masked]>
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) <[email-masked]> 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 <[email-masked]> 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) <[email-masked]> 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 <[email-masked]> 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):
>>>> [email-masked]
>>>> 
>>>> If you wish to submit further information on this problem, please
>>>> send it to [email-masked].
>>>> 
>>>> Please do not send mail to [email-masked] 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 [email-masked] with problems
>>> 
>>> 
>>> -- 
>>> Jeff Squyres
>>> [email-masked]
>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Bug-libtool mailing list
>>> [email-masked]
>>> https://lists.gnu.org/mailman/listinfo/bug-libtool
> 
> 
> 
> _______________________________________________
> Bug-libtool mailing list
> [email-masked]
> https://lists.gnu.org/mailman/listinfo/bug-libtool