bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building shared C++ libraries on openbsd


From: Carlo Wood
Subject: Building shared C++ libraries on openbsd
Date: Wed, 27 Sep 2000 12:51:59 +0200
User-agent: Mutt/1.1i

Hi libtool maintainers,

I already mailed openbsd with this bug (of them), but all I got back
was: "It works when you do: gcc -shared object.o -o lib.so"

And that turned out to be true (more or less).

Remains the problem that libtool doesn't do it that way...

Perhaps you are willing to workaround this very serious bug in openbsd?
Or otherwise tell me how I can work around it for my project, that
uses libtool, without hacking ltconfig myself :/.

Problem description
-------------------

When building a shared C++ library with libtool, constructors of
global objects are not called when the library is built the way
libtool does it.

libtool contains the following lines in ltconfig:

  openbsd*)
      archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linkopts'

When I mailed this problem to the openbsd maintainers, someone
mailed me back:

-----------------------------------------------------------------
Date: Sun, 24 Sep 2000 08:51:56 -0600 (MDT)
From: David Leonard <address@hidden>
Subject: Re: system/1394
To: address@hidden, address@hidden, address@hidden

Synopsis: Global constructors of shared libraries are not called.

State-Changed-From-To: open-analyzed
State-Changed-By: d
State-Changed-When: Sun Sep 24 08:50:36 MDT 2000
State-Changed-Why: 
It works when the shared library is built using 

        gcc -shared -o libglobal.so.0 global.o
-----------------------------------------------------------------

When I TRY that, I got LOTS and LOTS of errors in libgcc.a,
although the library is still built correctly.  This is caused
by the fact that gcc tries to link with -lgcc (something I
don't even want).

If we have a look at what gcc uses to make its shared libraries,
then we see:

~/tests>g++ -v -shared -o libglobal.so.0 global.o
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)
 /usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3/collect2 -Bshareable -x -dc 
-dp -o libglobal.so.0 -L/usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3 
global.o -lstdc++ -lm -lgcc -lc -lgcc
ld: /usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3/libgcc.a(_eh.o): RRS text 
relocation at 0x130a for "___frame_state_for"
ld: /usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3/libgcc.a(_eh.o): RRS text 
relocation at 0x1271 for "___frame_state_for"
ld: /usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3/libgcc.a(_eh.o): RRS text 
relocation at 0xedd for "___frame_state_for"
ld: /usr/lib/gcc-lib/i386-unknown-openbsd2.7/2.95.3/libgcc.a(_eh.o): RRS text 
relocation at 0xebb for "_memcpy"
.... etc etc etc (many)

It is easy to get rid of extra libraries; I propose to add -nostdlib

The following command allows me to build a correct shared library:

~/tests>g++ -shared -nostdlib -o libglobal.so.0 global.o -lstdc++ -lm -lc
~/tests>

No errors.

I am not sure if you want to add those -lstdc++ -lm -lc at all actually.
(It works perfectly without).

Please get back to me to tell me how I can make the current libtool
use THIS command to build a shared library on openbsd.  The solution
I have so far is:

1) Changing ltconfig, and adding it as part of my project
2) Adding an environment variable to @LIBTOOL@ when openbsd is
   detected in configure in order to pass the correct compiler path.

That is, I now use:

  openbsd*)
      archive_cmds='$CXXLD -shared -nostdlib -o $lib $libobjs $deplibs 
$linkopts'

And in configure.in:

case "$host" in
  *openbsd*) LIBTOOL="CXXLD=\$(CXXLD) $LIBTOOL" ;;
esac

Is there a better solution?

-- 
Carlo Wood <address@hidden>                        -=- Jesus Loves you -=-

PS CC To openbsd community



reply via email to

[Prev in Thread] Current Thread [Next in Thread]