Gents,
thanks for taking the time to explain stuff - hopefully, in the end,
we'll resolve this.
---
Firstly, issues with my choice of configure options might be
important - but they are not relevant to the underlying problem.
The basic problem is entirely repeatable with default options
("regress", for example, shows 128 unsupported libgomp tests).
I am happy to be 'blown out of the water' here - but I do want to
understand the limitations.
If gcc X.Y can deliver greater functionality than the default install
on darwinX then, IMO, I should be able to pass this onto my clients
and users.
Obviously, I want to do this in a secure manner, that does not break
the system for my clients, and is understandable by developers.
[* I am not trying to replicate your work Jack, but seeking a
different deployment solution - which is required in some cases].
We have strayed, to some extent, from the specific issue of TLS into
more general areas; but these are v. important areas (and one might
at least see this list as partial documentation for some future
engineer also trying to understand).
===
apropos emutls (I emailed Jakub, who kindly replied)
1/ The reason that emutls is in gcc_eh is because there must be only
one copy in an executable.
So, in the general case, when using emults, one must:
(a) link all parts of the executable using emutls statically (which
is tedious to achieve on darwin without moving all the dylibs to one
side)
(b) link with the libgcc_s.1that contains emutls.
so, AFAICT (at least on darwin) these are broken w.r.t emutls:
gcc main-progam.c -lgcc_eh -lsome-library-already-linked-to-emutls-
in-gcc_s.1 .....
gcc main-progam.c -lstatic-libgcc -lsome-library-already-linked-to-
emutls-in-gcc_s.1 .....
(in fact, D8 ld won't let you do the second unless "some-library-
already-linked-to-emutls-in-gcc_s.1" is already installed).
I have a hunch that this is, at least partially, the origin of
sporadic failures in crayptr2 (which has been one of the very few
tests using tls so far - because all the rest have been UNSUPPORTED
by the fails in dg target supports).
2/ If I understand correctly, one must link with the ex. handlers in
libSystem if one wants proper operation languages using exceptions
(i.e. the reason that --shared-libgcc is used in the testsuite). **
see also below.
So, my kludge to libgomp.exp "-lgcc_s.1" is probably broken with
respect to ex. handlers for g++, objc etc.
- unless it's acceptable for a single executable to get its EH code
from a newer libgcc_s.1
(i.e. is it a matter of consistency, or *must* the EH code absolutely
come from libSystem, for some other reason ?)
If the static libs are segregated because of these needs - then why
not segregate the dylibs?
I.E. put the EH code in libgcc_eh.so (which can then be ignored on
darwin)
====
apropos the general issue of supplying an enhanced gcc runtime set
onto darwinX
(assuming that the problems are fundamentally resolvable).
On 11 Dec 2008, at 00:13, Geoff Keating wrote:
On Dec 10, 2008, at 3:24 PM, IainS wrote:
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.
(a)
--enable-version-specific-runtime-libs**
should ensure that this is achieved without any risk of trampling on
the system (we certainly do not want to take responsibility for that).
(and with --program-suffix=-x.y.z allows me to have 4.3 and 4.4
installed along with apple-released 4.0 and 4.2 ... )
** providing one does *not* use --with-slibdir=/usr/lib (see below)
(b)
an alternative (especially attractive to me) is:
package a set of gccx.y libs with rpaths @executable_path/../lib
I can then deliver this as a user drag-installable app (perhaps
wasteful of disk space, but nicely self-contained) :
MyAppUsingGFortran.app
Contents/
MacOS/
MyAppUsingGFortran
lib/
libgfortran.dylib
etc.
libgcc_s.1.dylib
(c) There are all the other usual suspects ; put the libs in
DYLD_FALLBACK_LIBRARY_PATH etc. etc.
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.
I'm probably being dumb here, but some things are still not adding up
in my mind...
(a) my understanding (looking at the output of Wl,-t and Wl,-
whyload) is that libgcc_s.1 is ignored completely and the symbols are
resolved from libSystem
(b) If it is mandatory that gcc is configured with --with-slibdir=/
usr/lib for darwin, this should be mentioned somewhere (and I agree,
at that point, our cause looks pretty bleak).
(c) If we make the runtimes dependent on a specific version of the
system ; then shouldn't the runtimes reference that specific version
(e.g libgcc_s.10.4.dylib)?
(at the moment they all reference libgcc_s.1).
(d) currently, (AFAICT*) the runtimes link against, and are checked
against, the libgcc_s.1 that has *just been built* ; some trouble
could lie ahead when an application built with that is deployed onto
a live system. We also take the test output as indicative of the
compiler behavior - clearly, that can't be trusted if we test with a
different library set from the deployment.
* using DYLD_PRINT_LIBRARIES, LD_TRACE_* , and looking at crashlogs
from crashed test cases.
(e) Surely I should be able to (per executable) replace any symbol
(excluding ex. handlers, unless I replace the whole facility) with a
more up-to-date version - by referencing the appropriate library?
sorry for all the noise ... but your explanations are most valued,
Iain
