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 04:13:45PM -0800, Geoff Keating wrote:
>
> On Dec 10, 2008, at 3:24 PM, 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 second part here is the tricky part.  I would not recommend  
> installing your libgcc_s.1.dylib in /usr/lib, or anywhere else really,  
> since you don't know that it'll be compatible with the system one.
>
>>> 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
>
> That's normal, every program and shared library on Darwin does that.
>

Geoff,
   What I do for the FSF gcc packaging in fink is create a main gcc4X package and
gcc4X-shlibs split-off package. The FSF gcc compilers are all installed
within /sw/lib/gcc4.X. This works well since fink packages have build
and install dependencies so that I have conflict gcc43 and gcc44 (which
contain the compilers and headers) and allow the gcc43-shlibs and
gcc44-shlibs packages to co-exist so that anything built with an
earlier gcc4X package can keep running.
   I am confused about the issue with emutls. Check out PR35677. I am
seeing...

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

...built using FSF gcc configured with...

Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-20081209/configure --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
Thread model: posix
gcc version 4.4.0 20081210 (experimental) (GCC) 

I assume this implies that the emutls symbols should be accessible with the
correct linkage. Odd.
             Jack