Todd Vierling 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 ?
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 ...

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

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 ?

> : Is there any (semi-)automatic way how to find out if it's needed or not ?
> 
> 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' ?

As I understand manpage of ld.so, it's not ment to be that way.
Shared object's own .init and .fini functions are called in map time
if present, so it's definitely not true ...

-- 
Jaromir Dolecek <dolecek@ics.muni.cz>	http://www.ics.muni.cz/~dolecek/
-------------------------------------------------------------------------
It is better never to have been born.  But who among us has such luck?
One in a million, perhaps.