Hello Peter, * Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:36:22AM CET: > > I admit that I don't understand the failures like this one yet. > > Nelson H. F. Beebe wrote: > >> /convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS > >> $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist > >> stderr: > >> stdout: > >> libtool: link: gcj -shared -Wl,-z -Wl,text -Wl,-h -Wl,liba12.so.0 -o > >> .libs/liba12.so.0.0.0 -Wl,-z -Wl,allextract ./.libs/liba1.a > >> ./.libs/liba2.a -Wl,-z -Wl,defaultextract > > $GCJ is properly expanded to 'gcj' here. > > >> /convenience.at:267: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS > >> $LDFLAGS -o liba123.la A3.lo liba1.la liba2.la -rpath /notexist > >> stderr: > >> /local/build/bare/libtool-2.2/tests/testsuite.dir/64/libtool: line 7084: > >> -r: command not found > >> stdout: > >> libtool: link: -r -o .libs/liba123.la-1.o .libs/A3.o > > But here it is the empty string!
This should be $LD -r here, no? AFAICS this failure happens inside the low max_cmd_len test. This looks like a regression caused by the patch that removed _LT_SYS_DYNAMIC_LINKER from _LT_LANG_GCJ_CONFIG. (If that turns out to be true, I am glad we did not make this change for the other tags). This did not show up on GNU/Linux because there --whole-archive is used. Case in point: $ ./libtool --tag=GCJ --config|grep ^LD LD="/usr/bin/ld" LD="" Cheers, Ralf _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
