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

[Gary V. Vaughan]

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