libgcc problems

[pooh@msu.ru]

On 14-Jan-98 David Edelsohn wrote:
 
>  GCC now is getting into the realm of C++ compiler support libraries.  These
> are
> very carefully crafted for AIX.  GCC is trying to stuff its SVR4 policies
> into
> AIX and
> creating problems.  I am not sure exactly how to fix this and which problem
> to
> fix.  I think
> the right answer is to fix libgcc.a to utilize these symbols in a safe way
> instead of relying
> upon SVR4 linker details to hide the problem.  Obviously, that is easy for me
> to say from
> my perspective and my priorities although I cannot fix it myself.  The world
> is
> not SVR4/ELF
> -- at least not yet.

I guess that the *only* way to solve a problem of multiple instances
of libgcc's static variables for *all* AIXes is to move these statics
into shared object which can be inserted into libgcc.a. We shouldn't
afraid LD_LIBRARY_PATH problem - it doesn't exist for AIX native linker,
but all shared libraries will be nailed to libgcc location (so, we need
to relink them when changing gcc version).

>  Another idea: should collect2 not export any symbols with names reserved for
> the implementation, e.g. ones beginning with double underscore and ones
> beginning with
> single underscore and capital letter?

Good question! It seems to me that the answer should be yes except symbols
which can be inserted into code directly by compiler.

> I do not know whether _ptrgl and _savef14 was
> an illegal name or all single underscore names should be protected.  AIX does
> not
> prepend underscores to user symbols.  I do not know enough about the current
> implementation to state categorically that those symbols never need to be
> exported in
> some other instance.

We shouldn't take care about symbols like _ptrgl or _savef14 unless
we want to enable reexporting symbols from static libraries (exactly
a problem I got playing with libgcc), because these symbols are
contained in a static member of libc.a.

Regards,
Andrey.