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: <5e905daf11e59202b1420a972aeeb2469a3ebafa.1335178066.git.stefano.lattar...@gmail.com> From: Stefano Lattarini <stefano.lattar...@gmail.com> 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 <br...@clisp.org> Signed-off-by: Stefano Lattarini <stefano.lattar...@gmail.com> --- 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
