Subject: Re: C++ q: constructors not called for classes in shared lib ?
To: Jaromir Dolecek <>
From: Todd Vierling <>
List: current-users
Date: 02/02/1999 13:25:32
On Tue, 2 Feb 1999, Jaromir Dolecek wrote:

: > No, it's because it is extra code that has to be added to the library, and
: > there's no way around that.  On ELF systems, the equivalent to c++rt0.o is
: > crtbegin.o and crtend.o (linked separately at the beginning and end of the
: > object file list respectively), and Solaris needs just these in order to do
: > the same.  IIRC, you need these on Loonux as wel.
: Couldn't be linker (or g++, which invokes it) be made to DTRT
: when linking shared c++ library, i.e. add appropriate object into
: it automatically ?

The linker doesn't know if the library is a C++ shared library, and this is
standard procedure on nearly every OS.

: What about pkglibtool, shouldn't at least _it_ be aware of this
: speciality and handle building c++ shared libs without any extra
: efford ?

Pkglibtool doesn't know if the library is a C++ shared library.  This could
be added as a command line option.

: I have no experiences with building c++ libraries under those
: ^[LS].* systems, so I don't know if they require explicit addition
: of any special object files when building c++ shared library ...

Yep.  Nearly everyone does.

: Is it necessary to add those crtbegin.o & crtend.o on ELF systems
: explicitely to object file list or are they added automagically ?


: > If you have a C++ shared library, `you do.' The only place the NetBSD source
: > tree needs it is src/gnu/lib/libstdc++/Makefile.
: Maybe that's because it's the only c++ library in NetBSD source tree ? :)


: Can I read it as 'when you link against shared stdc++, all the static
: constructors in other shared c++ libs are called correctly on startup' ?

No; it just means that the constructors contained within libstdc++ (cin,
cout, cerr, for example) work properly.

-- Todd Vierling (Personal; Bus.