Re: Problem with shared libraries, exceptions, and global constructors

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 18-Aug-2003, Richard Henderson <rth@redhat.com> wrote:
> On Tue, Aug 19, 2003 at 10:44:18AM +1000, Fergus Henderson wrote:
> > The correct initialization sequence is one that initializes
> > the exception handling information for all .so files before calling
> > constructors of global objects in any files.
> 
> Ignore exception handling.  It's a red herring.

No, I think that is quite crucial.  Because exception handling is the one
which the user can't solve for themselves.  Other problems with cyclic
initialization dependencies can be solved (or avoided in the first place)
just by using appropriate C++ code.

> Indeed, with
> a recent ld on a recent linux system exception handling doesn't
> need to be initialized -- we read the data from ELF headers.

Great!  Problem solved, then, at least for GNU/Linux systems.

(If it doesn't work on other systems, then those other systems suck...
all the more reason to use GNU/Linux ;-)

> But the same problem ocurrs with any other sort of global state
> that needs constructing.  E.g. standard io.

No, for standard IO we have `basic_ios<charT,traits>::Init'.

For any other sort of global state that needs constructing, a
similar technique can be used.  Or programmers can just rely on the
order-of-initialization guarantees given in the C++ standard, if those
are sufficient for their application.

Obviously if there is a real cyclic initialization dependency, where
global variable x needs to be initialized before global variable y and
vice versa, then that is a programming error.  But if a cycle occurs
merely because fine-grained non-circular dependencies at the level of
individual variables have been conflated at the level of shared objects,
thus introducing a coarse-grained circularity, then it does not
necessarily indicate any design error or programming error.  The system
should support this.

> > Of course the C++ standard doesn't say anything about dynamic
> > linking, but it is undesirable for one feature (mutual recursion)
> > to interfere with another (dynamic linking).
> 
> I'm sorry if ELF dynamic linking was not designed with your
> requirements in mind.

Your description above implies that ELF dynamic linking meets my
requirements fine, provided you use a recent ld on a recent Linux system.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.