This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: import list creation on AIX and GCC 2.95-branch
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: import list creation on AIX and GCC 2.95-branch
- From: "Alexander N. Kabaev" <ak03 at gte dot com>
- Date: Tue, 23 Jan 2001 14:06:05 -0500 (EST)
- Cc: Bernd Schmidt <bernds at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Organization: Verizon Laboratories Inc.
On 23-Jan-2001 David Edelsohn wrote:
>>>>>> "Alexander N Kabaev" writes:
>
> Alexander> This cannot happen, AFAIK. By default, AIX linker will export all
> symbols
> Alexander> required by the shared objects being used by the particular
> application, i.e if
> Alexander> pure C program will be linked against C++ shared module, the
> linker will notice
> Alexander> that _get_eh_context(sp?) symbol is required and will export it
> even though
> Alexander> application itself does not use it.
>
> If the library is built with GCC configured for C++ and the
> application is built with GCC configured only for C, libgcc.a will not
> contain the C++ functions.
>
> David
You mean the build will fail at the linking time? I think it is fairly
reasonable to expect that the users linking in C++ shared objects will be doing
so using C++ aware compiler. If someone develops the shared library in C++
which is supposed to be used by the C only modules, he/she should use
explicitly linked in libgcc.a anyway.
Anyway, assuming that exceptions over shared library boundaries are working
correctly, what approach would you recommend to solve the shared exception
context problem on GCC 2.95.2 branch? Is building libgcc.so and libgcc_r.so the
right way to go?
----------------------------------
E-Mail: Alexander N. Kabaev <ak03@gte.com>
Date: 23-Jan-2001
Time: 13:11:46
----------------------------------