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

[Geoff Keating]

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

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).

while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter

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:


   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.  */

/* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib 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.

smime.p7s
Description: S/MIME cryptographic signature