Re: Preferred way to build shared objects from PIC archives?
On Sun, Aug 25, 2002 at 09:13:35PM -0400, Aaron M. Ucko wrote: The shared libraries in ncbi-tools6 and related packages currently start out as static archives of PIC objects, which then get turned into shared libraries with commands of the form gcc -shared -Wl,-soname=libddvlib.so.6 -o libddvlib.so.6.1.20020426 \ -Wl,-whole-archive libddvlib.a -Wl,-no-whole-archive This (admittedly roundabout) procedure works fine on i386, and has worked on other platforms until now, but as of some time in the past three months has started failing on arm with /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o): In function `__dummy': __dummy.o(.text+0x0): multiple definition of `__dummy' /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o)(.text+0x0): first defined here and a slew of similar messages. Is this a toolchain bug, or am I going about things the wrong way? (Building the shared libraries directly, while obviously preferable, would require too much tweaking to the awkward upstream build system.) Please Cc me on replies, as I do not subscribe to -devel. No, that should work fine. I don't know what's broken... you may wish to try extracting all the objects via ar and relinking them; that should be pretty easy, but I'm not sure it will help. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Preferred way to build shared objects from PIC archives?
Daniel Jacobowitz [EMAIL PROTECTED] writes: No, that should work fine. I don't know what's broken... you may wish to try extracting all the objects via ar and relinking them; that should be pretty easy, but I'm not sure it will help. That's actually how upstream does it, but then there are complications due to the fact that some libraries only contain *.glo instead of *.o (the former having OpenGL support enabled). Anyway, I managed to find the problem: on arm, the linker honors --no-whole-archive but silently ignores -no-whole-archive, so GCC's insertion of -lgcc -lc -lgcc leads to those errors when the linker sees the second -lgcc. (Sigh.) I have no idea why it's decided to become so picky, or why the problem only happens on arm, though I have to admit that the man page for ld only lists the double-dash form. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Preferred way to build shared objects from PIC archives?
The shared libraries in ncbi-tools6 and related packages currently start out as static archives of PIC objects, which then get turned into shared libraries with commands of the form gcc -shared -Wl,-soname=libddvlib.so.6 -o libddvlib.so.6.1.20020426 \ -Wl,-whole-archive libddvlib.a -Wl,-no-whole-archive This (admittedly roundabout) procedure works fine on i386, and has worked on other platforms until now, but as of some time in the past three months has started failing on arm with /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o): In function `__dummy': __dummy.o(.text+0x0): multiple definition of `__dummy' /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o)(.text+0x0): first defined here and a slew of similar messages. Is this a toolchain bug, or am I going about things the wrong way? (Building the shared libraries directly, while obviously preferable, would require too much tweaking to the awkward upstream build system.) Please Cc me on replies, as I do not subscribe to -devel. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
