Shared library annoyance with gcc-3_0-branch

[Clive Nicolson]

The scheme proposed by Fergus Henderson <fjh@cs.mu.oz.au> see:

>Hmm... this is such an ugly hack, I feel embarrassed to say it...

is along the lines of what is need for the "unique EH data" problem.

Linux and other OS's (or runtime systems) need either to provide EH
support as part of the "system" (VMS does this, as do other well
designed systems).

If the OS/RT does not provide the solution directly, then a mechanism
is needed where by 1 or more copies of the EH registering routines can
locate/create the unique EH data root in an atomic fashion. This mechanism
needs to be provided by the OS/RT or based on some hardware mechanism.

Unix hackers often use the file system to provide atomic name/value
systems, Fergus's setenv is attempting to do the same. A light weight
mechanism is needed such as named semphores in AmigaDos.

Each copy of the EH routines has then only to create or locate the EH root
once and then all is ok.

No mechanism of weak symbols etc will work with most current systems because
of the way typical unix linkers and dynamic loaders work.

I'm no unix expert, so it would be better if such a person posted a good description
of the "unique EH data" problem, and why the various suggested solutions will not
work.

My feeling is that it would be better if the linux gurus provided a backward
and forward compatible unique name/value system rather than a builtin EH system.
That would enable a general class of problems to be fixed once. The gcc EH code
for linux systems could then use this general mechanism. Other systems can do what
the gcc guys suggest or provide a such a mechanism too.

Clive