This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 18-Aug-2003, Richard Henderson <rth@redhat.com> wrote:
> If, from ANYONE's point of view, there is a cycle in the dependency
> graph, then there exists NO fully correct initialization sequence.
> 
> Period.

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.

e.g.
	initialize exception handling info for libbug1.so
	initialize exception handling info for libbug2.so
	call constructors for objects in libbug1.so
	call constructors for objects in libbug2.so

If GNU C++ uses an approach which does not support mutually recursive
modules in shared objects, then it fails to support all of standard C++
in the case when each translation unit is compiled to its own shared
object.  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).

> And, if I may be so bold, from a software engineer's point of view,
> if there exists such a cycle, then the project is badly designed.  It
> is a sign of layering violations or poor problem decomposition. 

I disagree.

Having mutually recursive shared libraries is not a good idea *currently*,
due to lack of portable tool support for this.  However, it does *not*
necessarily indicate bad design.

Often there may be natural mutual dependencies between components
at the same level in the layering.  If your hierarchy is wide rather
than deep, it makes sense to divide it into modules horizontally as
well as vertically.

Of course you can solve this by putting every component which has mutual
dependencies into a single shared object.  But that reduces modularity,
and is not necessarily desirable.  For example, it prevents these shared
objects from being individually upgradable.

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]