Subject: Re: C++ q: constructors not called for classes in shared lib ?
To: Jaromir Dolecek <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 02/02/1999 12:37:33
On Tue, 2 Feb 1999 19:17:10 +0100 (MET)
Jaromir Dolecek <email@example.com> wrote:
> 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 ?
> I understand it may not be needed in all cases, but adding
> the extra 523B (1.3I/i386) to shared library shouldn't hurt anyone ...
How does g++ know it's creating a shared library? g++ creates objects,
and an ld command builds the shared library. Since ld is invoked
separately (not by g++), the files must be included explicitly.
> What about pkglibtool, shouldn't at least _it_ be aware of this
> speciality and handle building c++ shared libs without any extra
> efford ?
How does pkglibtool know it's making a shared library out of C++ objects?
> 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 ...
> Is it necessary to add those crtbegin.o & crtend.o on ELF systems
> explicitely to object file list or are they added automagically ?
FWIW, _all_ shared libraries in ELF have crtbegin.o and crtend.o. That is
to say, we support constructors and destructors invoked by this method
in non-C++ objects, too.
Say, for example, you have a pthread library. Before main() is called, you
need to have the thread engine initialized. You could achieve this by
having a contructor vector for it. You can do this w/ the GNU toolchain
with something like the following:
void __pthread_init(void) __attribute__((__ctor__));
(I may have the attribute name wrong; I don't have the docs in front of me.)
It would actually be kind of cool if we could do this w/ a.out, too... but
the toolchain has built-in support for it in ELF. Guess it doens't matter
too much, since we'll be using ELF everywhere eventually, anyhow :-)
> 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's handled on a per-library basis.
-- Jason R. Thorpe <firstname.lastname@example.org>