libgcc problems with shared libraries

[Andrey Slepuhin]

On 12-Jan-98 David Edelsohn wrote:
>>>>>> Andrey Slepuhin  writes:
> 
> Andrey> I found a serious problem with libgcc using shared libraries on AIX.
> Andrey> The problem is following:
> Andrey> 1) Because every shared library is linked with static libgcc.a,
> Andrey> it has its own instances of libgcc's static variables.
> Andrey> 2) This causes the following effect: if, for example, a function
> Andrey> in shared library calls set_terminate(), then a local instance
> Andrey> of __terminate_func is changed, while a program linked with this
> Andrey> shared library uses its own instance of __terminate_func which
> Andrey> is still set to default.
> 
> Andrey> I can suggest the following possible workarounds:
> Andrey> 1) to move static variables into libstdc++,
> Andrey> 2) to create a shared libgcc,
> Andrey> but both are not good.
> 
>       This should not be limited to AIX.  It should affect any system
> using shared libraries where libgcc.a is a static library.

I tried to build a shared libgcc on AIX, but unsuccessfully. More
precisely, I obtained a library, but executables built with this
library were corrupted (it looks like linking process corrupts
nops after calls to libgcc's functions; I don't understand why 8-((( ).
However I successfully done the following operation:
1) I moved __terminate_func from libgcc2.c to separate source file,
   defining it in libgcc2.c as as extern.
2) I built libgcc.a without __terminate_func.
3) I built a shared object with __terminate_func.
4) I inserted this shared object into libgcc.a (this is possible on AIX).

After above steps I could build correct executables and the problem
with multiple instances gone away.

Regards,
Andrey.