Re: libtool 1.5.10 fails nopic test on Solaris

[Ralf Wildenhues]

[ Note for mailing list readers:
This is from an older thread about Solaris problems,
http://lists.gnu.org/archive/html/bug-libtool/2004-09/msg00171.html
Ralf Menzel confirmed that my patches I posted in
http://lists.gnu.org/archive/html/bug-libtool/2004-11/msg00134.html
worked for him, but reported failures for quote.test and
func_extract_archives.test.  The Solaris patches will be dealt with
in another posting. ]

As it turns out, we get three bugs (at least) for the price of one
bugreport:

* Ralf Menzel wrote on Fri, Dec 17, 2004 at 04:54:40PM CET:
> Ralf Wildenhues <address@hidden> writes:
> > * Ralf Menzel wrote on Thu, Dec 16, 2004 at 06:56:13PM CET:
> >> Ralf Wildenhues <address@hidden> writes:
> >> In the output of "make check" for libtool-2-0-patched there is the
> >> following fragment:
> >> 
> >> --- snip ---
> >> SKIP: demo-nopic.test
> >> PASS: demo-make.test
> >> PASS: demo-exec.test
> >> --- snip ---
> >> 
> >> I wonder whether the SKIP for demo-nopic.test should trigger that
> >> demo-make.test and demo-exec.test are skipped too.
> >
> > Good point.  Don't know if that's worth the hassle for me, though.
> > (I don't mind to have a couple of PASSes that should really be SKIPs,
> > this inaccuracy is innocent.)
> 
> Yes, though it may be a little bit confusing if one sees something
> like this:
> 
> --- snip ---
> PASS: demo-pic.test
> PASS: demo-make.test
> FAIL: demo-exec.test
> SKIP: demo-nopic.test
> PASS: demo-make.test
> FAIL: demo-exec.test
> --- SNIP ---

ACK.  But I don't know a simple workaround for the 1.5 testsuite, and
we are moving away from it anyway.  This is a cosmetic issue only.

> > Please rerun these tests with
> > $ make check VERBOSE=x TESTS='quote.test func_extract_archives.test'
> 
> See attachment

[ pasted here in parts: regarding func_extract_archives.test failure ]

| === Running func_extract_archives.test
| ar: creating libfoo.a
| rm -fr .libs/libfoo
| mkdir .libs/libfoo
| rm -fr .libs/libfoo/libfoo.a
| mkdir .libs/libfoo/libfoo.a
| (cd .libs/libfoo/libfoo.a && ar x
| +/home/menzel/src/testing/gcc/new-patches/libtool-1-5-patched/tests/libfoo.a)
| libtool: warning: object name conflicts; renaming object files
| libtool: warning: to ensure that they will not overwrite
| cp /home/menzel/src/testing/gcc/new-patches/libtool-1-5-patched/tests/libfoo.a
| +.libs/libfoo/libfoo.a/libfoo.a
| ./func_extract_archives.test: -r: is not an identifier
| rm -f .libs/libfoo/libfoo.a/libfoo.a
| FAIL: func_extract_archives.test

I guess, the shell's `read' does not understand `-r'.  Can you confirm
this?  Does your shell documentation match this?  Please try the patch
in attachment #1 (against branch-1-5; branch-2-0 should be similar, but
against config/ltmain.m4sh).  I don't think we need -r here.

Peter, could you also change this for HEAD when you apply your
respective patch?



[ regarding quote.test failure ]

| = trying: \\ quoting
| = failed:  gcc -c "-DVAR=       est\" foo.c  -fPIC -DPIC -o .libs/foo.o
|  gcc -c "-DVAR= est\" foo.c -o foo.o >/dev/null 2>&1

This is the "$echo computed for the wrong shell" bug for which I have
yet to contemplate a bug.  Try again with
  CONFIG_SHELL=$FOO $FOO configure [...]

with $FOO the shell that configure would've chosen.  For branch-2-0 and
HEAD, you'd also need the patch from
http://lists.gnu.org/archive/html/bug-libtool/2004-12/msg00161.html
I think.

[time passes]

And another (unrelated) bug: $lt_ECHO is matched wrongly.  See patch in
attachment #2 against branch-2-0 and HEAD.

> --- snip ---
> [anarion:libtool-1-5-patched]137> ./libtool --config | grep echo=
> echo="echo"
> [anarion:libtool-1-5-patched]138> sed 1q ./libtool
> #! /bin/sh
> --- snip ---

This fits my assumption.

> [snip]
> > I wonder why quote.test is not failing in branch-2-0..
> 
> This might contain a clue:
> 
> --- snip ---
> [anarion:libtool-1-5-patched]139> cd ..
> [anarion:new-patches]140> head -1 */libtool
> ==> libtool-1-5/libtool <==
> #! /bin/sh
> 
> ==> libtool-1-5-patched/libtool <==
> #! /bin/sh
> 
> ==> libtool-2-0/libtool <==
> #! /bin/bash
> 
> ==> libtool-2-0-patched/libtool <==
> #! /bin/bash
> --- snip ---
> 
> Seems like branch-2-0 uses bash if it's there.

I would not be so sure about the stability of this.
The bug mentioned above makes the problem vanish after the first
automatic reconfiguration (that's why it remained hidden for so long, I
guess), because the remaking will run

  cd $top_builddir && $SHELL ./config.status

and then configure will run under the correct shell.

> To do some test I created two further directories:
> libtool-1-5-patched-with-bash and libtool-2-0-patched-with-sh. There I
> did a reconfigure with the appropriate setting of CONFIG_SHELL. When I
> called quote.test it work in both cases. You can find the verbose logs
> as attachments.
> 
> You may get some insight from this:
> 
> --- snip ---
> [anarion:new-patches]197> cd libtool-1-5-patched-with-bash
> [anarion:libtool-1-5-patched-with-bash]198> ./libtool --config | grep -i echo=
> echo="echo"
> [anarion:libtool-1-5-patched-with-bash]199> cd ../libtool-2-0-patched-with-sh
> [anarion:libtool-2-0-patched-with-sh]200> ./libtool --config | grep -i echo=
> ECHO="/home/menzel/sw5.9-gcc3.4.3/bin/echo"
> [anarion:libtool-2-0-patched-with-sh]201> cd ../libtool-2-0-patched
> [anarion:libtool-2-0-patched]202> ./libtool --config | grep -i echo=
> ECHO="echo"
> --- snip ---

This fits my assumption as well.

> > ,-- output of \"cvs diff\" for branch-2-0
> > | diff -u -p -r1.51.2.2 bootstrap
> > | --- bootstrap   8 Oct 2004 21:44:43 -0000       1.51.2.2
> > | +++ bootstrap   16 Dec 2004 18:02:02 -0000
> > | @@ -42,7 +42,8 @@ EOF
> > |  rm -rf `find . -path './{arch}' -prune -o \( -name autom4te.cache -o 
> > -name libtool \) -print`
> > | 
> > |  # Delete stale files from previous libtool versions.
> > | -rm -f acinclude.m4 config/ltmain.sh libltdl/config.h
> > | +#rm -f acinclude.m4 config/ltmain.sh libltdl/config.h
> > | +rm -f acinclude.m4 libltdl/config.h
> > | 
> > |  if test -z "$reconfdirs"; then
> > |    reconfdirs=". `ls -1d tests/*demo tests/*demo[0-9]`"
> > | @@ -56,7 +57,9 @@ set -- `sed '/AC_INIT/{s/[][,()]/ /g; p;
> > |  # We don't have all the substitution values to build ltmain.sh from this
> > |  # script yet, but we need config/ltmain.sh for the libtool commands in
> > |  # configure, and ltversion.m4 to generate configure in the first place:
> > | -rm -f ./config/ltmain.sh ./m4/ltversion.m4
> > | +#rm -f ./config/ltmain.sh ./m4/ltversion.m4
> > | +rm -f ./m4/ltversion.m4
> > | +touch ./config/ltmain.m4sh
> > |  test -f Makefile || { makefile=Makefile; cp Makefile.am $makefile; }
> > |  make ./config/ltmain.sh ./m4/ltversion.m4 ./libtoolize.in 
> > ./tests/defs.in \
> > |      top_srcdir=. PACKAGE="$2" VERSION="$3" M4SH="autom4te -l m4sh"
> > *snip*
> >
> > I'm sure you had a reason for doing this (I haven't looked into it).
> > Care to elaborate?
> 
> Hm, let's see if I can remember some details ...
> 
> I had some problems with the bootstrap script. First I had to install
> a "find" that knowns the "-path" options. Later

Hmm.  Not too sure if I want to go through the hassle of making
bootstrap portable.  (Might be advantageous for user feedback, though).

> I somehow managed to arrive at a situation where I had a hard time to
> get something to work again. I think that I accidentally had two "make
> check" jobs running at the same time. In this situation I tried to do
> a "make distclean". But this didn't work. Some recursively called
> Makefile (I think it was the one in tests/depdemo, but I'm not sure)
> stopped the execution and told me to first do a "make distclean"! I
> was flabbergasted.

Hehe, the to-be-replaced testsuite sucks.  You had to learn it the hard
way (a `make distclean' in tests/depdemo only would have probably
worked, else try `rm -rf $top_builddir/tests/depdemo' iff you do a VPATH
build).

> So I tried to call the bootstrap script. But (needless to say) this
> didn't work either. If I remember correctly there was a circular
> dependency where the Makefile that generates config/ltmain.sh calls
> configure, which needs config/ltmain.sh to exist to work. That's why a
> made the changes above. I can probably undo them now that everything
> is fine again.

Yep, do that.  Maybe we need to look into this anyway, however.

Regards,
Ralf

read-r.diff
Description: Text document

lt-echo-quote.diff
Description: Text document