Re: aix shared libraries and collect2

[Andrey Slepuhin <pooh at msu dot ru>]

Andreas Damm wrote:
> >>
> >> When trying to create a c++ shared library myself 1/ was the main problem. The
> >> libraries are used as an extension mechanism in my case and are therefore loaded
> >> explicitly at runtime via dlopen. If the executable was not compiled with gcc
> >> then the library will not load.
> >
> >Note that this is true for *all* platforms. You may not mix C++ code
> >compiled
> >by gcc with code compiled by other compilers.
> 
> I do not think that is entirely true. Yes, I will have problems with different
> c++ abi's and support libraries -- but if a shared library contained a c
> interface then I cannot see many problems (unless you use import lists).

Probably yes, if your library doesn't have global objects with
ctors/dtors. In such situation disabling import lists should help.

> Why are multiple instances of libgcc global symbol's a problem -- is it just
> memory size?

Of course, no. The problem is because AIX linker cannot merge multiple
instances
together. This makes usage of shared C++ libraries very limited. Imagine
an exception thrown from shared library to main application while there
are
different instances of internal EH data structures. Understand? AFAIK,
at
least EH and RTTI will be broken, may be something else.

> >> Regarding 3/: I thought the reason why libgcc is not a shared library but gets
> >> included into every executable was mainly to be independent of compiler updates.
> >> Using the import file mechanism employed under aix means making libgcc shared --
> >> just not in a straight forward way -- fact is the libraries load libgcc at
> >> runtime from the executable.
> >
> >No, this is not the same thing as making libgcc shared. Consider upgrading
> >your compiler. Then if you are using shared libgcc you'll need to recompile
> >all libraries and executables. With import file hack - you need not, because
> >libgcc's symbols are *already* hardcoded into executable.
> 
> Libgcc does get loaded dynamically from c++ shared libraries -- making it
> shared. It is true that just updating the compiler does no harm to applications
> using those shared libraries. But if after the update you compile an executable
> with the c++ shared libraries you might be in trouble as they will use the
> updated libgcc.

Mmm... It is not guaranteed at all that you can compile an executable
via new compiler and link it with old shared libraries due to possible
ABI changes. But *all* old executables linked with old libraries will
continue to work. This is not true if you are using shared libgcc. Or
you should keep all old versions of libgcc.

> >It can be disabled easy, but believe me, if you are using AIX4.2 or
> >later you'll loose more than you'll win.
> 
> What exactly will I lose?

As I said above, at least EH and RTTI with shared libraries will be
broken.

Regards,
Andrey.