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

[Geoff Keating <geoffk at apple dot com>]

On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:

> On Wed, Dec 10, 2008 at 02:55:11PM +0000, IainS wrote:
> > On 10 Dec 2008, at 14:43, Jack Howarth wrote:
> >
> > > shipped by Apple with its OS releases. I think what you want to do
> > > make sure you are using the FSF libgcc's and not the system ones
> > > while having environmental MACOSX_DEPLOYMENT_TARGET unset. The  
> > > latter
> > > step will cause the unversioned libgcc to be used with all the newer
> > > symbols specific to the FSF gcc 4.4 release (that are not listed in
> > > the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files).
> >
> > I have not found a way (MACOSX_DEPLOYMENT_TARGET set or unset) of
> > getting the loader to look at the FSF libgcc_s.1.dylib unless I
> > specifically name it on the command line with -lgcc_s.1
> >
> > That does work ( as does -lgcc_eh. )
> >
> > I guess I misunderstood the purpose of libgcc_s10.x as being "all the
> > symbols added since this release"
> >
> > It would help if someone could point me at some clear documentation
> > about what
> >
> > libgcc_eh
> > libgcc_s.1
> > libgcc_s.10.X
> >
> > *should* contain.
> >
> > other than that, it's a case of returning to some solution which
> > involves a tls.exp... etc.
> >
> > thanks,
> > Iain
>
> Iain,
>   Actually, on reflection, I'm not really sure how one gets the
> complete set of symbols out of libgcc on darwin any more. The patch...
>
> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00475.html
>
> would suggest that the compiler now defaults to the libgcc of
> the system it is running on, so it is unclear what unsetting
> MAC_OS_X_DEPLOYMENT_TARGET would achieve. Perhaps Geoff can
> clarify this behavior and explain how the unversioned set
> of libgcc symbols can be used?


All this is documented in darwin.h:

/* Support -mmacosx-version-min by supplying different (stub)  
libgcc_s.dylib
   libraries to link against, and by not linking against libgcc_s on
   earlier-than-10.3.9.

   Note that by default, -lgcc_eh is not linked against!  This is
   because in a future version of Darwin the EH frame information may
   be in a new format, or the fallback routine might be changed; if
   you want to explicitly link against the static version of those
   routines, because you know you don't need to unwind through system
   libraries, you need to explicitly say -static-libgcc.

   If it is linked against, it has to be before -lgcc, because it may
   need symbols from -lgcc.  */

libgcc_s.10.x.dylib are stub libraries that list the symbols that were  
shipped in libgcc_s.1.dylib in Mac OS version 10.x.  The compiler  
links with '-lgcc_s.10.x -lgcc' and so any particular routine comes  
either from libgcc_s.10.x.dylib, if it's there, or from libgcc.a, if  
it wasn't present on that system.

The particular 'x' is based on the -mmacosx-version-min flag.  A long  
time ago the MACOSX_DEPLOYMENT_TARGET environment variable was used  
for this but it should not be used today, because environment  
variables are bad.

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.

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.

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