Re: libtool, multilib and test "duplicate convenience archive names"
On Thursday, October 20, 2011 11:07:13 PM Roumen Petrov wrote:
> Hi Andreas and Bo,
>
> Please could you clarify build of 64-bit system for 32 bit.
Hi Roumen,
> Roumen Petrov wrote:
> > 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 ?
>
> Traced to
>
> 2002-11-18 Andreas Jaeger , Bo Thorsen
>
> * libtool.m4: Support linking of 32-bit libraries with ld
>
> on the x86-64, ppc64, s390x and sparc64 GNU/Linux systems.
Sorry, I don't remember that change anymore and thus cannot help,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, multilib and test "duplicate convenience archive names"
Hi Andreas and Bo, Please could you clarify build of 64-bit system for 32 bit. Roumen Petrov wrote: 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 ? Traced to 2002-11-18 Andreas Jaeger , Bo Thorsen * libtool.m4: Support linking of 32-bit libraries with ld on the x86-64, ppc64, s390x and sparc64 GNU/Linux systems. Roumen ___ https://lists.gnu.org/mailman/listinfo/libtool
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: libtool & MULTILIB
Steve Ellcey <[EMAIL PROTECTED]> writes: > > Should I just tell the user to do two builds, > with different options and different install directories? For what it's worth, in GMP that's what we've done. In principle there could be different libc functions and stuff in different ABIs, so a fresh run of configure is the safest way to be sure of getting the right result. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool & MULTILIB
I have a general opensource packaging/build question that is sort of related to libtool (I think) and was hoping someone could answer it or provide me with a pointer. For an opensource package that consists of one or more libraries and that uses configure, automake, libtool, and the usual packaging tools, is there a standard way to say that you want multiple versions of a library built? For example with GCC there are GCC specific variables and macros you set to build multiple versions of libgcc and put them in different directories; say a 32 bit version in one directory and a 64 bit version in another. I belive these macros are specific to GCC, and are not something handled generically by any tool used in the packaging of GCC and I was wondering if there was a more generic way of handling this for simpler packages? So for example, if I was shipping an opensource product that consisted of sources that get built into a single library and I wanted the user to be able to build two versions of that library, one 32 bits and one 64 bits, what would I do? Should I just tell the user to do two builds, with different options and different install directories? Or could I use the -print-multi-lib option on GCC to see what versions I should build? What if the user isn't using GCC? Or is there some better way to handle this that I don't know about? Is libtool even involved in this question at all? Steve Ellcey [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
