libgcc problems with shared libraries

[Andrey Slepuhin]

On 13-Jan-98 Andrey Slepuhin wrote:
> 
> 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.
> 
> On AIX4.2 and later problem can be solved by the following way:
> 1) Linking shared library without libgcc but with -G ld flag (i.e. ready
>    for run-time linking).
> 2) Linking executable with -brtl ld flag.
> I checked that this method works, but not compatible with older AIXes.
> 
> Question: should I try to build shared libgcc, or this is unacceptable?

I found one more workaround for AIX: if a symbol from static library
(e.g. libgcc) is reexported when creating a shared object, then
only *one* instance of such symbol is used. However such solution cause
the following problems:
1) Linker warns about duplicated symbols.
2) collect2 cannot decide what symbols from static library are needed
   for concrete shared object; exporting all symbols from libgcc will
   cause a growth of shared object size, because *all* members of
   libgcc.a will be statically linked into this shared object. This
   can be solved with two-pass linking: first pass *without* static
   libraries, collecting linker diagnostics about undefined symbols,
   and the second pass *with* static libraries, exporting only those
   symbols which were undefined during first pass. This possibly can
   eliminate linker warnings in some cases, but not all. Coding such
   solution will be slightly difficult, but possible. The disadvantage
   of such method is necessary additional linker pass.

I prepared a small testsuite for testing discussed problem (attached).
This testsuite should work on most platforms. Untar, edit makefile if
needed and type "make check". If no linker errors/warnings are
generated and all three addresses in output will be the same, then
there is no problem with multiple instances on tested platform.

Regards,
Andrey.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiple-instances-test.tar.gz
Type: application/x-gzip
Size: 629 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/19980114/3c533c55/attachment.bin>