Subject: Re: C++ q: constructors not called for classes in shared lib ?
To: Jaromir Dolecek <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
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 firstname.lastname@example.org; Bus. email@example.com)