[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 23:41:01 +0000 |
close 19370
reopen 19730
Just in case 19730 was mistakenly closed by my fat fingers earlier :-/
--
Gary V. Vaughan (gary AT vaughan DOT pe)
> On 22 Dec 2014, at 21:22, Gary V. Vaughan <address@hidden> wrote:
>
> 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
>
>
>
>
> _______________________________________________
> Bug-libtool mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-libtool