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

[Jack Howarth <howarth at bromo dot med dot uc dot edu>]

On Wed, Dec 10, 2008 at 11:24:28PM +0000, 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 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
>
> and, if we want to be able to use gomp, then I we need to find a way to 
> provide emutls.
>
> This, obviously, should not be by linking with gcc_eh (since people  
> would want the current system-provided exception mechanism to continue to 
> work, I imagine).
>
> thanks, for the explanations - it's been an educational day!
>
> Iain

Iain,
   I think the problem is that we are forcing --shared-libgcc on those
testcases that are coming up as UNSUPPORTED. If I recall correctly the
--shared-libgcc was added to resolve problems where the libgomp testsuite
harness wasn't linking with the g++...

http://gcc.gnu.org/ml/gcc/2007-03/msg00479.html
http://gcc.gnu.org/ml/gcc/2007-03/msg00485.html
http://gcc.gnu.org/ml/gcc/2007-03/msg00495.html
http://gcc.gnu.org/ml/gcc/2007-03/msg00532.html

The correct fix for gcc 4.5 would be to backout the use of -shared-libgcc
from the libgomp testsuite on darwin and fix the test harness to use
g++ when appropriate.
                  Jack
ps I would also note that you shouldn't need...

--enable-version-specific-runtime-libs -- enable-__cxa_atexit --enable-threads -- disable-nls

I only use...

configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9

and this links in the emutls symbols fine via -static-libgcc. Look at PR35677. The libgomp.fortran/crayptr2.f90
on darwin shows...

nm crayptr2.exe | grep emut
00001cd0 t ___emutls_get_address
00001c90 t ___emutls_register_common
00002014 d ___emutls_v.ip.1499
00001f10 t _emutls_destroy
00001ed0 t _emutls_init
00002090 b _emutls_key
00002040 d _emutls_mutex
00002094 b _emutls_size

but is linked with -static-libgcc.