[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