🚀 go-pugleaf

In article <4115@dell.dell.com> james@raid.dell.com (James Van Artsdalen) writes:
>In <PCG.89Oct31193848@emerald.cs.aber.ac.uk>, pcg@emerald.cs.aber.ac.uk (Piercarlo Grandi) wrote:
>
>> All we need now is to persuade MDT that the .init/.fini sections
>> handling, and the rest of the System V.3.2 paraphernalia, should
>> be put into the mainline G++ setup,
>
>I do not think .init sections are necessarily a good idea.  Any code
>placed in a .init section should probably not call malloc(3c), since
>malloc(3c) will not have been initialized yet (in the shared library
>case).  collect may be a hack, but the issue of when constructors and
>destructors are run seems much more controllable than with .init.

James,

You are correct.  When I used extra sections to bring up g++, I created
two new sections called .ctors and .dtors.

Note however that the problem that you have described is a *general* problem
with the C++ language, i.e. the order in which global objects get
initialized (i.e. constructed) is not defined.  Thus, your *own*
constructors (when used for global objects) cannot reliably call
library routines (of any kind, but especially if the routines to be
called are themselves hunks of C++ code that rely on prior "initialization"
of their own globals for proper operation).

P.S.  Please send me my diskettes!

// rfg