On Tue, 2 Feb 1999 19:17:10 +0100 (MET) 
 Jaromir Dolecek <jdolecek@per4mance.cz> 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 <thorpej@nas.nasa.gov>