bug#11306: Automake 1.11d on MacOS X

[Stefano Lattarini]

On 04/22/2012 08:10 PM, Bruno Haible wrote:
> Hi Stefano,
> 
>>> FAIL: t/lex-libobj
>>> ==================
>>
>>> + ./configure 'LEXLIB=-L /lib'
>>> checking for a BSD-compatible install... 
>>> /Users/bruno/data/local-macos/bin/install -c
>>> ...
>>> + make
>>> cc -DPACKAGE_NAME=\"lex-libobj\" -DPACKAGE_TARNAME=\"lex-libobj\" ...
>>> foo.c:1033: warning: 'yyunput' defined but not used
>>> mv -f .deps/foo.Tpo .deps/foo.Po
>>> cc -DPACKAGE_NAME=\"lex-libobj\" -DPACKAGE_TARNAME=\"lex-libobj\" ...
>>> mv -f .deps/yywrap.Tpo .deps/yywrap.Po
>>> cc  -g -O2   -o foo foo.o -L /lib yywrap.o 
>>> ld: file not found: /lib
>>> collect2: ld returned 1 exit status
>>> make: *** [foo] Error 1
>>> + exit_status=2
>>>
>>> On this machine, /usr/bin/lex is a shell script that invokes /usr/bin/flex.
>>> There is a /usr/lib/libfl.a.
>>> Everything looks right up until the line
>>>   ./configure 'LEXLIB=-L /lib'
>>> I don't know how _adding_ a -L option to a compiler/linker command is meant
>>> to hide a library that is installed in /usr/lib ??
>>>
>> Oh, it's not intended to work like that; simply, setting $LEXLIB to a 
>> non-empty
>> value ensures that configure won't look for a "lex library", and simply rely 
>> on
>> the $LEXLIB to provide it, if needed.  We could override $LEXLIB with any 
>> valid
>> (list of) linker options.  Does the problem disappear if you use:
>>
>>   ./configure LEXLIB='-L .'
>>
>> instead?
> 
> Modifying a test apparently requires me to have the same exact Autoconf
> version (2.68) as you did. What an annoyance!
>
Yes, the test suite inter-dependencies are correct but overly pedantic ...
something to be fixed for 1.12.1.  Feel free to open a new bug report about
that if you want, to be extra-sure we won't forget about the issue.

> [SNIP]
> 
> Result: it still fails:
> 
> cc  -g -O2   -o foo foo.o -L . yywrap.o
> ld: in ., can't map file, errno=22
> collect2: ld returned 1 exit status
> make: *** [foo] Error 1
> + exit_status=2
> + set +e
> + cd /Users/bruno/data/build/multibuild-2074/macosx/automake-1.11d
> + test no = yes
> + case $am_explicit_skips in
> + test 2 -eq 0
> + keep_testdirs=yes
> + am_keeping_testdirs
> + case $keep_testdirs in
> + return 0
> + set +x
> lex-libobj: exit 2
> 
> But setting LEXLIB to just whitespace makes the test succeed:
> 
> 
> diff -r -u automake-1.11d.orig/t/lex-libobj.sh automake-1.11d/t/lex-libobj.sh
> --- automake-1.11d.orig/t/lex-libobj.sh       2012-04-13 17:44:41.000000000 
> +0200
> +++ automake-1.11d/t/lex-libobj.sh    2012-04-22 20:01:27.000000000 +0200
> @@ -68,7 +68,7 @@
>  $MAKE distclean
>  
>  # Force "no system lex library".
> -./configure LEXLIB='-L /lib'
> +./configure LEXLIB=' '
>  grep LIBOBJS Makefile # For debugging.
>  grep '^LIBOBJS *=.*yywrap.*\.o' Makefile # Sanity check.
>  $MAKE
>
Thanks.  I will apply the attached patch then (comments and reviews welcome).

>>> Apparently, the "automake-1.11d ..." command [run with the AUTOMAKE_JOBS
>>> environment variable set to a value > 1] got a bus error. It is a shell
>>> script that runs perl (/usr/bin/perl, version 5.8.8).
>>>
>> I have tested automake with perl 5.8.8, 5.10.1, 5.12.4 and even perl 5.6.2,
>> never seeing any error in these tests.  So it seems like an an issue with
>> perl multithreading on your system.  Could you somehow verify whether this
>> is truly the case?
> 
> How would I do this?  I don't know anything about Perl.
>
Ah, OK,  I wasn't aware of that.  I'm no expert either, but I hope I'll be
able to cook up (in the next days) a check of some sort.  For the moment,
let's ignore this issue (which would affect a real user only if he exported
the AUTOMAKE_JOBS variable).

Thanks,
  Stefano

0001-tests-fix-spurious-failure-on-Mac-OS-X.patch
Description: Text Data