libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [patch #6691] FreeMiNT support to libtool 1.5.26 (tested)
Date: Mon, 27 Apr 2009 23:56:48 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Alan,

sorry for the delay.

* 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.

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?

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?

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).

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


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.


> 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.

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.

> 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'

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

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"
   ;;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]