Re: libgcc problems with shared libraries

[Andrey Slepuhin <pooh at msu dot ru>]

On 14-Jan-98 Jeffrey A Law wrote:
>   In message <XFMail.980113125643.pooh@msu.ru>you write:
>   > 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?
> Generally, building libgcc as a shared library is a bad idea.  It relates
> back to the LD_LIBRARY_PATH issues.

Yes, I understand. But can you say which systems can support
something similar the above solution for AIX4.2?

>   > P.S. I discussed a problem with some specialists in MSU, and they said
>   >      that libgcc shouldn't contain such static variables as
> __terminate_func
> Agreed.  This is the root of the problem.

Except __terminate_func there are some other static variables in libgcc
referred to exception handling, and a top of dynamic handler chain in
particular. So, I'm not sure if a program will always correctly catch
an exception thrown from shared library. Some time ago somebody reported
that he has problems throwing an exception from shared library (even
on ELF platform!) - may be this is the same problem?
But moving all exception handling code into libstdc++ is not a good
solution too, because this can make impossible the use of libstdc++
with different egcs versions. However I think that such things as
__terminate_func and top_elt (and may be something else) are stable
enough and can be moved into libstdc++ without much efforts.
Any comments?

Regards,
Andrey.

P.S. Moving some of eh code into libstdc++ may cause problems for
     those who don't want to use libstdc++ at all (I know some
     *very good* C++ programmers who don't like libstdc++ :-))