libtool, multilib and test "duplicate convenience archive names"
Hello All, I wonder how to build and test on a 64 bit platform a 32 bit libtool version. First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with CC and CXX set to 'gcc|g++ -m32', i.e. multilib . The libtool regression suite fail in test case : 25: duplicate convenience archive names FAILED (duplicate_conv.at:83) From testsuite.log: .../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la stderr: .../ld: Relocatable linking with relocations from format elf32-i386 (.libs/c.o) to format elf64-x86-64 (cee.o) is not supported stdout: libtool: link: .../ld -r -o cee.o .libs/c.o --whole-archive a/.libs/liba.a b/.libs/liba.a --no-whole-archive Eric PAIRE post a patch about linker emulation mode - ref. http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html . Based on Eric's suggestion I try to build without to set --host, i.e. as native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers. As result -m elf_i386 is added to linker (LD) and libtool regression test pass with: 114 tests behaved as expected. 12 tests were skipped. Any thought on this ? Regards, Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath's with colons
Hi, sorry somehow I've missed your reply. On Friday 07 October 2011, Eric Blake wrote: > On 10/05/2011 11:07 AM, Ruediger Meier wrote: > > > > Does anybody of you know whether and how it's possible to specify > > directories with colons like > > /usr/lib/bad:dir/ > > as LD_LIBRARY_PATH at runtime or as rpath at linking time? > > Probably not possible, for the same reason that using directories > with : in their name as part of $PATH is not possible. Sorry. Is this documented somewhere or is this obvious that there is no way to "escape" the colon somewhow? The problem is that rpath or LD_LIBRARY_PATH of libtool's convenience binaries will fail if the build directory path contains colons. IMO libtool should abort or at least warn if somebody tries to build within such broken path. I was hitting this issue in practice when compiling xz from tar ball. Everything seemed to work but make check failed because it was using using a global installed liblzma instead of the freshly build one. cu, Rudi ___ https://lists.gnu.org/mailman/listinfo/libtool
