On Wed, Dec 10, 2008 at 07:39:35PM +0000, IainS wrote:
>
> On 10 Dec 2008, at 19:05, Jack Howarth wrote:
>
>> On Wed, Dec 10, 2008 at 06:23:18PM +0000, IainS wrote:
>>>
>>> On 10 Dec 2008, at 18:10, Mike Stump wrote:
>>>
>>>> On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
>>>>>> If I now understand correctly, the symbols present in updated
>>>>>> versions of
>>>>>> libgcc that are not in the "stock" system libgcc on darwin - need
>>>>>> to be
>>>>>> mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
>>>>>> emutls ones
>>>>>> were not present causing linkage failures that were silently
>>>>>> UNSUPPORTING
>>>>>> a lot of tests.
>>>>
>>>> No, those files are meant to describe what was shipped in the past
>>>> on
>>>> darwin as part of darwin. So, changing them isn't quite the right
>>>> way
>>>> to do this. Best to put them in the libgcc.a file and let them
>>>> link in
>>>> statically. Is there some reason why this doesn't work? I can
>>>> answer
>>>> questions and offer advice, feel free to cc me.
>>>
>>> thanks MIke,
>>>
>>> the basic issue is that TLS (as used extensively within gomp) is
>>> implemented, at present, as an emulation (emutls).
>>>
>>> This is present in libgcc_s.1.dylib and libgcc_eh.a
>>>
>>> However, as Jack says, it seems currently very difficult to persuade
>>> gcc
>>> to extract symbols from this un-versioned lib (without mentioning it
>>> specifically on the CL)
>>>
>>> Whilst this is a possible work-around for getting the test suite to
>>> work, it concerns me that it's quite obscure and prone to being
>>> missed
>>> out, forgotten, and/or fragile.
>>>
>>> There is an added inconvenience in that darwin8's ld command behaves
>>> differently from darwin9's
>>>
>>> the only work-around I've found that gives equal results on d8 and
>>> d9 is
>>> to specify -lgcc_eh
>>>
>>> these approaches seem like temporary hacks .. and I wonder what a
>>> good
>>> long-term solution would be?
>>>
>>> cheers,
>>> Iain
>>
>> Iain,
>> I know we have...
>>
>> if [istarget *-*-darwin*] {
>> lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
>> }
>>
>> in libgomp/testsuite/lib/libgomp.exp. So you have to make sure
>> that gets overridden if you wan to use --static-libgcc.
>> This change was discussed here...
>>
>> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html
>>
>> Jack
>
> Yes, that's understood. However:
>
> --static-libgcc does not work (any more, if it used to) with D8 (unless
> you install the compiler before make check).
>
> libgomp.1.dylib => libgcc_s.1.dylib and D8's ld command objects.
>
> I already commented that if you do --static-libgcc with D9 then
>
> libgomp -> libgcc_s.1
> mainline -> statically linked with libgcc.a
>
> this doesn't seem a good idea.
>
> using libgcc_eh.a minimises this (in the case of the libgomp tests)
> because the only symbols that happen to be sourced are the __emutls
> ones.
>
> However, that's not a general case.
>
> =-----
>
> I suppose I'd expected the current *compiler* symbols to take precedence
> over the system ones (unless I specifically demand that the linked binary
> is usable w/out delivering the updated runtimes).
>
> For any of this to be useful to an end-user we must accept that the
> libgfortran/libgomp .. etc etc. runtimes would have to be installed on
> the end-user's system (since they are not currently part of any D8/D9
> system).
>
> `pologies, if I'm being slow... there is a large learning curve here...
>
> cheers,
> Iain
Iain,
Since your objections are entirely related to the testsuite when
FSF has not been installed, perhaps it would be more productive to see
if the testsuite in libgomp can be reworked to handle darwin when
gcc is uninstalled.
Jack
