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
