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
