Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[Geoff Keating <geoffk at apple dot com>]

On Dec 10, 2008, at 3:24 PM, IainS wrote:

> Thanks Geoff,
> that's v. useful doc.
>
> On 10 Dec 2008, at 22:36, Geoff Keating wrote:
>
> > On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
> >
> > > On Wed, Dec 10, 2008 at 02:55:11PM +0000, IainS wrote:
>
> <snip>
>
> > To use the 'unversioned set' implies that you're compiling for a  
> > version of Mac OS that Apple has not yet created and most likely  
> > will never exist.  This is not useful.
> >
> > One way to get extra runtime support is put routines in libgcc.a  
> > which can be statically linked into executables if they aren't  
> > present in the system.
>
>
> if one did -lgcc_s.10.x -lgcc_s.1   would that break it?
> ... should it not pick up only the unresolved symbols from s.1
>
> ( you would also have to be  prepared to install libgcc_s.1 in a  
> suitable place).

The second part here is the tricky part.  I would not recommend  
installing your libgcc_s.1.dylib in /usr/lib, or anywhere else really,  
since you don't know that it'll be compatible with the system one.

> > The routines in libgcc_eh.a are routines which should normally  
> > never be statically linked into executables, because they won't  
> > work if you do that; they must be in the system.  If you need a  
> > routine that's in libgcc_eh.a, and it's not in the system, you're  
> > out of luck; you can't use it.  You'd need to rewrite it so it can  
> > handle being linked into multiple executables, or you'd need to  
> > create a new shared library, put the routine in it, and ship that  
> > shared library with every executable you create.
>
> OK, we've got quite a bit of work to do then, all the runtime libs  
> (gfortran, stdc++v3, gomp, ffi, java)  link on libgcc_s.1.dylib

That's normal, every program and shared library on Darwin does that.

Attachment: smime.p7s
Description: S/MIME cryptographic signature