Re: [patch #6691] FreeMiNT support to libtool 1.5.26 (tested)

[Alan Hourihane]

On Mon, 2009-04-27 at 23:56 +0200, Ralf Wildenhues wrote:
> Hi Alan,
> 
> sorry for the delay.

no problem Ralf, I appreciate the response.

> * Alan Hourihane wrote on Wed, Apr 22, 2009 at 09:13:37PM CEST:
> > On Wed, 2009-04-22 at 20:34 +0200, Ralf Wildenhues wrote:
> > > * Alan Hourihane wrote on Wed, Apr 22, 2009 at 06:09:33PM CEST:
> > > > These came up as the failures. The tests 16 & 73 seems to be exposing a
> > > > linker bug that I'm looking at now. I'm sure the others are due to the
> > > > fact that FreeMiNT doesn't have shared libraries or dlopen support. So I
> > > > guess I need to tweak some other configuration files someplace.
> > > 
> > > Can you send the tests/testsuite.log file also?  Thanks!
> > 
> > Sure, attached.
> 
> The log file indicates that running the new testsuite alone took 13
> hours already.  Whew.  Thank You for going through this pain.

No problem, it's a slow m68k CPU.

> Perusing the log, I see that I need more information about this system,
> listed as m68k-atari-mint.  First off, is there some web site with good
> information about the compiler, linker, runtime linker on this system?

It's GCC 4.2.4 (at the moment) to get to 4.3.3 soon. And binutils
2.19.51.0.3. It's all standard GNU utils though. 

> You stated that this system does not provide any kind of shared
> libraries.  Is it planned that this changes at some point in the future?

Unlikely in the short to medium term.

> More comments inline.
> 
> > uname -m = falcon
> > uname -r = 1.17a
> > uname -s = FreeMiNT
> > uname -v = 4.4
> > 
> > /usr/bin/uname -p = mc68060
> > /bin/uname -X     = unknown
> 
> > testsuite: starting at: Wed Apr 22 01:15:39 Local time zone must be 
> > set--see zic manual page 2009
> > 1. libtoolize macro installation (libtoolize.at:83): ok     (0m1.440s 
> > 0m22.160s)
> [...]
> > testsuite: ending at: Wed Apr 22 14:11:45 Local time zone must be set--see 
> > zic manual page 2009
> > testsuite: test suite duration: 12h 56m 5s
> 
> 
> > 16. duplicate_conv.at:25: testing ...
> 
> > ./duplicate_conv.at:79: $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS 
> > -o cee.$OBJEXT c.lo a/liba.la b/liba.la
> > stderr:
> > stdout:
> > libtool: link: (cd .libs/cee.ox/liba.a && ar x 
> > "/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/a/.libs/liba.a")
> > libtool: link: (cd .libs/cee.ox/lt1-liba.a && ar x 
> > "/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/b/.libs/liba.a")
> > libtool: link: /j/usr/m68k-atari-mint/bin/ld -r -o cee.o     
> > .libs/cee.ox/liba.a/a.o  .libs/cee.ox/lt1-liba.a/a.o 
> > .libs/cee.ox/lt1-liba.a/b.o 
> > libtool: link: rm -fr ".libs/cee.ox"
> > ./duplicate_conv.at:81: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main 
> > main.$OBJEXT cee.$OBJEXT
> > stderr:
> > gcc: Internal error: Bus Error (program ld)
> > Please submit a full bug report.
> > See <URL:http://bugs.gentoo.org/> for instructions.
> > stdout:
> > libtool: link: gcc -g -O2 -o main main.o cee.o 
> > ./duplicate_conv.at:81: exit code was 1, expected 0
> > 16. duplicate_conv.at:25: 16. duplicate convenience archive names 
> > (duplicate_conv.at:25): FAILED (duplicate_conv.at:81)
> 
> Two bugs here: one known bug in ltmain.m4sh, in that we do reloading of
> non-PIC objects wrongly (c.o is forgotten).

O.k. so we do nothing here ?

> The second issue looks like an error in gcc or the link editor.  I bet
> it's a problem with the earlier 'ld -r', that tends to be buggy
> sometimes, as it typically receives less testing.  However, as it
> happens after the libtool bug, it may not be all that relevant to fix
> it.  You can try whether it still shows up after
>   cd tests/testsuite.dir/16
>   (cd .libs/cee.ox/liba.a && ar x 
> "/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/a/.libs/liba.a")
>   (cd .libs/cee.ox/lt1-liba.a && ar x 
> "/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/b/.libs/liba.a")
>   /j/usr/m68k-atari-mint/bin/ld -r -o cee.o c.o .libs/cee.ox/liba.a/a.o 
> .libs/cee.ox/lt1-liba.a/a.o .libs/cee.ox/lt1-liba.a/b.o
>   rm -fr ".libs/cee.ox"
>   ../../../libtool --mode=link gcc -g -O2 -o main main.o cee.o

Yes, it's the -r option that causes the linker bug. We'll be fixing ld
for this case anyway.

> Test 73 Run tests with low max_cmd_len (cmdline_wrap.at:28) is just
> another instance of this, so there is no need to look at it in further
> detail.

Right.

> > 41. old-m4-iface.at:107: testing ...
> 
> > ./old-m4-iface.at:156: ./ltdldemo; lt_status=$?; if test $lt_status -eq 0; 
> > then :;
> >        elif test "X$host" != "X$build" && \
> >             { test -x "./ltdldemo" || test -x "./ltdldemo"$EXEEXT; }
> >        then (exit 77); else (exit $lt_status); fi
> > Not enabling shell tracing (command contains an embedded newline)
> > --- /dev/null       1970-12-31 01:35:46.000000000 +0000
> > +++ /tmp/libtool-2.2.6-mint/tests/testsuite.dir/at-stderr   2009-04-22 
> > 02:57:07.000000000 +0000
> > @@ -0,0 +1 @@
> > +error fetching func: symbol not found
> > stdout:
> > ./old-m4-iface.at:156: exit code was 1, expected 0
> > 41. old-m4-iface.at:107: 41. AC_WITH_LTDL (old-m4-iface.at:107): FAILED 
> > (old-m4-iface.at:156)
> 
> There are several test failures that are similar.  They look like there
> is some bug in the dlpreloading support in Libtool on this system.

Remember we don't have dlopen support.

> I'm still pondering how I can investigate those in a better way without
> access to the system; I haven't been able to get a similar issue to show
> up on Linux.

O.k, anything I can help with - let me know.

> > 45. lt_dladvise.at:28: testing ...
> 
> > ./lt_dladvise.at:365: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main 
> > main.$OBJEXT $preloaded $modules $LIBLTDL
> > stderr:
> > ./.libs/libdepend.a(moddepend.o): In function `g':
> > /tmp/libtool-2.2.6-mint/tests/testsuite.dir/45/moddepend.c:5: undefined 
> > reference to `i'
> > /tmp/libtool-2.2.6-mint/tests/testsuite.dir/45/moddepend.c:5: undefined 
> > reference to `f'
> > stdout:
> > libtool: link: rm -f .libs/main.nm .libs/main.nmS .libs/main.nmT
> > libtool: link: (cd .libs && gcc -g -O2 -c -fno-builtin "mainS.c")
> > libtool: link: rm -f ".libs/mainS.c" ".libs/main.nm" ".libs/main.nmS" 
> > ".libs/main.nmT"
> > libtool: link: gcc -g -O2 -o main main.o .libs/mainS.o  
> > ./.libs/libpreload.a ./.libs/libdepend.a 
> > /tmp/libtool-2.2.6-mint/tests/../libltdl/.libs/libltdlc.a
> > libtool: link: rm -f ".libs/mainS.o"
> > ./lt_dladvise.at:365: exit code was 1, expected 0
> > 45. lt_dladvise.at:28: 45. lt_dlopenadvise library loading 
> > (lt_dladvise.at:28): FAILED (lt_dladvise.at:365)
> 
> Ah, this test needs to avoid the moddepend module on systems without
> shared libraries.  Can you try this patch?  After applying it should
> be sufficient to run
>   make check-local TESTSUITEFLAGS='-v -d -x -k lt_dlopenadvise'

It failed a little later now, log attached.

> and that shouldn't take all that long either.  OK to add you to THANKS?

No problem on the THANKS file :-)

Many thanks Ralf!

Alan.

> Thanks,
> Ralf
> 
>       Fix testsuite failure of lt_dlopenadvise test on FreeMiNT.
>       * tests/lt_dladvise.at (lt_dlopenadvise library loading): Do not
>       build moddepend for systems without shared libraries.
>         * THANKS: Update.
>       Report by Alan Hourihane.
> 
> diff --git a/tests/lt_dladvise.at b/tests/lt_dladvise.at
> index 3bf9bee..a48d00f 100644
> --- a/tests/lt_dladvise.at
> +++ b/tests/lt_dladvise.at
> @@ -318,8 +318,11 @@ dlpreloadable='preload'
>  # are reporting not able to accept the global hint to lt_dlopenadvise().    #
>  # ------------------------------------------------------------------------- #
>  
> -case $host_os in
> -cygwin* | mingw* | cegcc*)
> +have_shared=false
> +$LIBTOOL --features | grep 'enable shared libraries' >/dev/null && 
> have_shared=:
> +
> +case $host_os,$have_shared in
> +cygwin* | mingw* | cegcc* | *,false)
>    # These hosts do not support linking without -no-undefined
>    CPPFLAGS="$CPPFLAGS -DHAVE_UNDEFINED_SYMBOLS=0"
>    ;;

testsuite.log
Description: Text Data