Re: import list creation on AIX and GCC 2.95-branch

["Alexander N. Kabaev" <ak03 at gte dot com>]

  Well, I have fixed "exceptions over shared libraries" problem on my AIX 4.2.1
box and with the automatic import list creation brought back from the previous
CVS revision of the collect2.c file GCC is now able to generate the code which
is good enough to run all the omniORB samples without any ill effects. OmniORB
code is heavity multithreaded and naturally tends to throw exceptions across
the shared library boundaries often :) As far as I can tell, the use of "."
imports is the only way on AIX to share the same exception context among all
the modules in the executable which does not require the shared version of the
libgcc. The people who need to create shared libraries to be used with non-gcc
compiled executables should be able to work around the problems you are
describing by linking libgcc.a into the shared module explicitly.


On 23-Jan-2001 David Edelsohn wrote:
>>>>>> Bernd Schmidt writes:
> 
>> Could someone please sched some light on why automatic import file creation
>> for
>> shared libraries on AIX has been disabled on the gcc-2.95-branch?
> 
>> Do you mean this patch?
> 
>> 2000-08-25  David Edelsohn  <edelsohn@gnu.org>
>> * collect2.c (use_import_list): Always return 0 (disable).
> 
>> This was installed before I became involved.  David, can you explain what
>> it is doing?
> 
>       Use of the automatic import list was disabled because it was wrong
> and broken.  It was an incorrect optimization attempt to provide libgcc
> symbols through a shared library by treating the main application as the
> shared library.  It is a guarantee that the main program will provide
> those symbols, and that commitment is not always true.
> 
>       This design fails when one wishes to create a shared library with
> GCC and link or dynamically load the shared library with a non-GCC program
> (e.g., a Java JIT not compiled with GCC).  This also fails if the library
> utilizes C++ but the main program is just C, so the libgcc.a C++ symbols
> are not present.  The shared object must be self-contained with respect to
> GCC support library dependencies.  See the AIX "Exec Format Error" FAQ
> entry addressed at the NUMEROUS people who have encountered this problem.
> 
>       The one place where the old functionality provided some benefit
> was by registering only one exception handling table for the entire
> application.  However, exception handling does not work very well across
> shared libraries in gcc-2.95 for other reasons, so this is no great loss
> compared to the problems that it creates.
> 
>       In GCC 3.0 libgcc is itself created as a true shared library.
> 
> David
> ==============================================================================
> =
> David Edelsohn                                      T.J. Watson Research
> Center
> dje@watson.ibm.com                                  P.O. Box 218
> +1 914 945 4364 (TL 862)                            Yorktown Heights, NY
> 10598

----------------------------------
E-Mail: Alexander N. Kabaev <ak03@gte.com>
Date: 23-Jan-2001
Time: 11:15:16
----------------------------------