Re: aix shared libraries and collect2

["Andreas Damm" <dammy at dwl dot co dot uk>]

>Andreas Damm wrote:
>>
>> It seems to me the way collect2 works on aix with respect to libgcc is
flawed.
>> The way it works now is to not add any code from libgcc to shared libs but to
>> import them from the executable which will eventually load that library. This
>> creates several problems:
>>
>> 1/ This approach only works if the executable was compiled with gcc and if
the
>> executable was linked with that library;
>> 2/ Exceptions will not work -- not even if they are thrown and caught within
the
>> library;
>
>Would you please supply a testcase?


The module where I encountered this error is has quite a lot of dependencies on
roguewave's tools library -- right now I do not have the time to recreate a
small test case

>
>> 3/ The versions of gcc the executable and the library were compiled with must
>> not mismatch.
>>
>> 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). And
that is not a far fetched idea either -- one might want to reimplement a library
in c++ but still conform to a certain interface in order to make use of (and
reuse) class libraries or generally to make code more managable.
In my case I am writing extension modules for our product which make heavy use
of the STL, roguewave and in house libraries.

>> But even if the executable was compiled with gcc
>> the library can only be loaded with varying success because only the bits of
>> libgcc actually used are in the executable the rest gets garbage collected,
e.g.
>> if the library uses rtti or exceptions and the executable does not then I am
out
>> of luck.
>
>Yes, you are right, but please understand one thing: I *do not* see a
>way
>to avoid multiple instances of global symbols from libgcc other than a
>hack

>with import files. Yes, making libgcc shared will solve this problem but


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

>it is
>currently unacceptable by gcc maintainers. Probably, if your dlopened
>modules
>are self-contained, i.e. they do not, for example, throw exceptions that
>should
>be catched in main executable, it would be useful to disable import
>lists when
>building such libraries. Otherwise you only may hack your executable to
>force including necessary symbols from libgcc.
>


Import lists should be disabled by default as they only work in certain
cicumstances and should only be used by people who understand the implications
of using them.

>> 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.

>> IMHO the import file mechanism under aix should be abondoned as it is only
>> correct in a limited number of setups.
>
>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 I agree with that making usage
>of
>import lists for libgcc as option will be a right thing. But, I don't
>remember why, this idea was abandoned (probably because this adds one
>more
>platform-specific option).
>


What exactly will I lose?

>So, if you'll have an excellent idea how to correctly setup gcc for
>using shared C++ libraries on AIX, please send it out. Of course,
>current
>solution is not ideal, but it works in most cases. At least I
>succesfully
>used exceptions, shared libraries and multithreading together.
>
>Regards,
>Andrey.

Bye.