On Wed, Dec 10, 2008 at 02:36:22PM -0800, 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:
>>>
>>> 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.
>
Geoff,
I am confused. Assuming one builds FSF gcc configured with
--enable-threads, shouldn't that create a libgcc.a for FSF gcc
containing the ___emutls_get_address and ___emutls_get_address
symbols? If so, shouldn't those be drawn in through the normal
'-lgcc_s.10.x -lgcc' linkage of the FSF gcc compilers? I am
wondering if Iain is short-circuiting with his configuration
settings...
configure flags: --prefix=/Volumes/ScratchCS/gcc-440-install --
target=i386-apple-darwin9.5.0 --enable-languages=c,c+ +,fortran,objc,obj-c++
--enable-version-specific-runtime-libs -- enable-__cxa_atexit --enable-threads
--enable-checking=release -- disable-nls --program-suffix=-4.4.0
Jack
ps Why doesn't the darwin build default to enable threads?
