Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Ralf Wildenhues wrote: > * Peter O'Gorman wrote on Fri, Mar 07, 2008 at 08:40:08AM CET: >> Peter O'Gorman wrote: >>> Ralf has already checked in a workaround for gcj being unable to create >>> objects/executables. I guess I will add to that so it tests that an >>> executable created by the compiler will actually run. >> Ok? > > Yes, provided that you've tested it ... > >> +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore]) >> +rm -f foo1.o foo1.obj foo1$(EXEEXT) > > ... after eliminating those syntax errors, $EXEEXT instead of $(EXEEXT). Well that makes me feel silly :) Thanks. I tested that it ran the test on GNU/linux with GCJ=gcj and skipped when I set GCJ to 'gcj -L/home/pogma/lib -lzero' without /home/pogma/lib in the dynamic linker's search path. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 08:40:08AM CET: > Peter O'Gorman wrote: > > > > Ralf has already checked in a workaround for gcj being unable to create > > objects/executables. I guess I will add to that so it tests that an > > executable created by the compiler will actually run. > > Ok? Yes, provided that you've tested it ... > +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore]) > +rm -f foo1.o foo1.obj foo1$(EXEEXT) ... after eliminating those syntax errors, $EXEEXT instead of $(EXEEXT). Cheers, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Peter O'Gorman wrote: > The gcj in /usr/local/bin does indeed add -liconv, thank you for > confirming my suspicion. > > Ralf has already checked in a workaround for gcj being unable to create > objects/executables. I guess I will add to that so it tests that an > executable created by the compiler will actually run. Ok? Peter -- Peter O'Gorman http://pogma.com 2008-03-07 Peter O'Gorman <[EMAIL PROTECTED]> * tests/convenience.at (Java convenience archives): Skip test if gcj cannot compile a working executable from .java files. Report by Nelson H. F. Beebe. Index: tests/convenience.at === RCS file: /sources/libtool/libtool/tests/convenience.at,v retrieving revision 1.9 diff -u -r1.9 convenience.at --- tests/convenience.at 6 Mar 2008 19:59:25 - 1.9 +++ tests/convenience.at 7 Mar 2008 07:38:32 - @@ -262,8 +262,10 @@ # There are just too many broken gcj installations out there, either missing # libgcj.spec or unable to find it. Skip this test for them. if test $i -eq 1; then -AT_CHECK[($GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) -rm -f foo1.o foo1.obj +AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) +AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore]) +rm -f foo1.o foo1.obj foo1$(EXEEXT) fi $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.java ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Nelson H. F. Beebe wrote: >>> Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32] >>> Hmm. Does the gcj on this system add -liconv at link time, but somehow >>> not add it to the rpath? > Thank you for the response. > The separate need for -Wl,-rpath,/path/to/something or > -R/path/to/something in addition to -L/path/to/something is common on > many Unix flavors if executables are to run without an environment > variable like LD_LIBRARY_PATH having to be set. We don't use the > ld.so.conf feature on GNU/Linux, because we found that it broke too > many gnome packages. The gcj in /usr/local/bin does indeed add -liconv, thank you for confirming my suspicion. Ralf has already checked in a workaround for gcj being unable to create objects/executables. I guess I will add to that so it tests that an executable created by the compiler will actually run. > >>> What does: >>> >>> gcj -### -o /dev/null /dev/null >>> >>> show? > > I have two versions of gcj on this system: > > % \which -a gcj > /usr/local/bin/gcj > /usr/bin/gcj > > % /usr/bin/gcj --version > gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9) > > % /usr/local/bin/gcj --version > gcj (GCC) 3.4.3 > > % /usr/bin/gcj -### -o /dev/null /dev/null > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/libgcj.spec > rename spec lib to liborig > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/u > sr/share/info --enable-shared --enable-threads=posix --disable-checking > --with-s > ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions > --enable-java-aw > t=gtk --host=i386-redhat-linux > Thread model: posix > gcc version 3.4.6 20060404 (Red Hat 3.4.6-9) > "/usr/libexec/gcc/i386-redhat-linux/3.4.6/collect2" "--eh-frame-hdr" "-m" > "elf_ > i386" "-dynamic-linker" "/lib/ld-linux.so.2" "-o" "/dev/null" > "/usr/lib/gcc/i386 > -redhat-linux/3.4.6/../../../crt1.o" > "/usr/lib/gcc/i386-redhat-linux/3.4.6/../.. > /../crti.o" "/usr/lib/gcc/i386-redhat-linux/3.4.6/crtbegin.o" > "-L/usr/local/sys/ > FortranPlus/fplus_55h/lib" "-L/usr/lib/gcc/i386-redhat-linux/3.4.6" > "-L/usr/lib/ > gcc/i386-redhat-linux/3.4.6" > "-L/usr/lib/gcc/i386-redhat-linux/3.4.6/../../.." " > /dev/null" "-lgcc_s" "-lgcc" "-lgcj" "-lm" "-lpthread" "-lz" "-ldl" "-lgcc_s" > "- > lgcc" "-lc" "-lgcc_s" "-lgcc" "/usr/lib/gcc/i386-redhat-linux > > % /usr/local/bin/gcj -### -o /dev/null /dev/null > Reading specs from > /export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4 > .3/specs > Reading specs from > /export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4 > .3/../../../libgcj.spec > rename spec lib to liborig > Configured with: ../gcc-3.4.3/configure > Thread model: posix > gcc version 3.4.3 > > "/export/local/i386-linux/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.3/collect2" > > "--eh-frame-hdr" "-m" "elf_i386" "-dynamic-linker" "/lib/ld-linux.so.2" "-o" > "/d > ev/null" "/usr/lib/crt1.o" "/usr/lib/crti.o" > "/export/local/i386-linux/bin/../li > b/gcc/i686-pc-linux-gnu/3.4.3/crtbegin.o" > "-L/export/local/i386-linux/bin/../lib > /gcc/i686-pc-linux-gnu/3.4.3" "-L/export/local/i386-linux/bin/../lib/gcc" > "-L/us > r/local/sys/FortranPlus/fplus_55h/lib" > "-L/usr/local/lib/gcc/i686-pc-linux-gnu/3 > .4.3" > "-L/export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../. > ./../i686-pc-linux-gnu/lib" > "-L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../ > ../../i686-pc-linux-gnu/lib" > "-L/export/local/i386-linux/bin/../lib/gcc/i686-pc- > linux-gnu/3.4.3/../../.." > "-L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../.. > " "/dev/null" "-lgcc_s" "-lgcc" "-lgcj" "-lm" "-liconv" "-lpthread" "-ldl" > "-lgc > c_s" "-lgcc" "-lc" "-lgcc_s" "-lgcc" > "/export/local/i386-linux/bin/../lib/gcc/i6 > 86-pc-linux-gnu/3.4.3/crtend.o" "/usr/lib/crtn.o" Thank you. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Nelson H. F. Beebe wrote: > libtool: link: gcj -g -O2 --main=foo1 -o main_static .libs/foo1.o > ./.libs/liba1.a > +++ /local/build/bare/libtool-2.2/tests/testsuite.dir/at-stderr > 2008-03-04 15:26:49.0 -0700 > @@ -0,0 +1 @@ > +./main_static: error while loading shared libraries: libiconv.so.2: cannot > open shared object file: No such file or directory > ./convenience.at:277: exit code was 127, expected 0 > 19. convenience.at:229: 19. Java convenience archives (convenience.at:229): > FAILED (convenience.at:277) Hmm. Does the gcj on this system add -liconv at link time, but somehow not add it to the rpath? What does: gcj -### -o /dev/null /dev/null show? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
