Subject: bug#11306: Automake 1.11d on MacOS X

From: Stefano Lattarini <[email-masked]>
Date: Mon, 23 Apr 2012 12:51:14 +0200

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
>From 5e905daf11e59202b1420a972aeeb2469a3ebafa Mon Sep 17 00:00:00 2001
Message-Id: <5e905daf1[email-masked]>
From: Stefano Lattarini <[email-masked]>
Date: Mon, 23 Apr 2012 12:47:43 +0200
Subject: [PATCH] tests: fix spurious failure on Mac OS X

See automake bug#11306.

* t/lex-libobj.sh: We used to pass LEXLIB='-L /lib' to the ./configure
invocation, to prevent it from explicitly searching for a "lex library".
But the linker on MacOS X 10.5 apparently chokes on that:

  cc -g -O2  -o foo foo.o -L /lib yywrap.o
  ld: file not found: /lib
  collect2: ld returned 1 exit status

So, we now instead pass LEXLIB=' ', which being non-empty is enough
to prevent the search of a "lex library".  And since we are at it,
enhance comments on this non-obvious usage.

Co-authored-by: Bruno Haible <[email-masked]>
Signed-off-by: Stefano Lattarini <[email-masked]>
---
 t/lex-libobj.sh |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/t/lex-libobj.sh b/t/lex-libobj.sh
index 3bc2981..1c3b0cc 100755
--- a/t/lex-libobj.sh
+++ b/t/lex-libobj.sh
@@ -67,8 +67,13 @@ grep LIBOBJS Makefile # For debugging.
 $MAKE
 $MAKE distclean
 
-# Force "no system lex library".
-./configure LEXLIB='-L /lib'
+# Force "no system lex library".  Setting LEXLIB to a non-empty value
+# ensures that configure won't search for a "lex library", and simply
+# rely on the LEXLIB to provide it, if needed.  So, by setting LEXLIB
+# to a blank but non-empty value we can foo configure into thinking
+# that no system-level library providing a 'yywrap' function is
+# available.  See also discussion on automake bug#11306.
+./configure LEXLIB=' '
 grep LIBOBJS Makefile # For debugging.
 grep '^LIBOBJS *=.*yywrap.*\.o' Makefile # Sanity check.
 $MAKE
-- 
1.7.9.5