This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: darwin, symbol visibility differences between libgcc_s and libgcc
- From: IainS <developer at sandoe-acoustics dot co dot uk>
- To: Mike Stump <mrs at apple dot com>
- Cc: Jack Howarth <howarth at bromo dot med dot uc dot edu>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 20 Dec 2008 09:27:10 +0000
- Subject: Re: darwin, symbol visibility differences between libgcc_s and libgcc
- References: <20081220022423.GA4128@bromo.med.uc.edu> <6C8DF00B-9492-41F7-B3B2-8E6131706E29@apple.com>
On 20 Dec 2008, at 03:51, Mike Stump wrote:
Yes, libgcc_s is carefully built with carefully controlled exports.
They are controlled by:
gcc/libgcc-std.ver
when someone wants to export one of the symbols, they can just add
it to the list.
OK, my question was phrased poorly;
I understand the mechanism - what I don't understand is the rationale.
What is the benefit of splitting the publicly exported symbols
between libgcc_s.1.dylib and libgcc.a?
This forces us to -lgcc, even in a hypothetical newly-released case,
where the libgcc_s.1.dylib is completely up-to-date.
Iain