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] |
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.
multiple-instances-test.tar.gz
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |