On Wed, Dec 10, 2008 at 08:27:50AM +0000, IainS wrote:
> Hi all,
>
> ref: http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html, PR32765 and
> http://gcc.gnu.org/ml/fortran/2008-12/ msg00118.html
>
> NOTE to gurus: the whole libgcc_eh, libgcc_s.{10.x, 1} thing is quite
> hard to understand.
> I searched gcc.pdf, gccint.pdf (0 hits) and the list (not much) ... and
> google (mostly speculation).
>
> In the end I had to RTSC....
>
> If I now understand correctly, the symbols present in updated versions of
> libgcc that are not in the "stock" system libgcc on darwin - need to be
> mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The emutls ones
> were not present causing linkage failures that were silently UNSUPPORTING
> a lot of tests.
>
> It's also possible that key tests might fail on 64bit processors (see
> the referenced threads) which could also result in "UNSUPPORTS"
> appearing and disappearing sporadically.
>
> "bootstrap-lean" and "make check" on powerpc-apple-darwin8 and i386-
> apple-darwin9 (both on 64 bit processors).
>
> this results in:
> g++ +1 supported
> gcc +4 supported
> libgomp +126 supported
>
> I'll [EMAIL PROTECTED] processor builds during today.
>
> do you think this is the proper solution ?
>
> Iain
>
> =======
>
> Index: gcc/config/i386/darwin-libgcc.10.5.ver
> ===================================================================
> --- gcc/config/i386/darwin-libgcc.10.5.ver (revision 142592)
> +++ gcc/config/i386/darwin-libgcc.10.5.ver (working copy)
> @@ -83,3 +83,5 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
> Index: gcc/config/i386/darwin-libgcc.10.4.ver
> ===================================================================
> --- gcc/config/i386/darwin-libgcc.10.4.ver (revision 142592)
> +++ gcc/config/i386/darwin-libgcc.10.4.ver (working copy)
> @@ -79,3 +79,5 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
> Index: gcc/config/rs6000/darwin-libgcc.10.5.ver
> ===================================================================
> --- gcc/config/rs6000/darwin-libgcc.10.5.ver (revision 142592)
> +++ gcc/config/rs6000/darwin-libgcc.10.5.ver (working copy)
> @@ -87,3 +87,6 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
> +
> Index: gcc/config/rs6000/darwin-libgcc.10.4.ver
> ===================================================================
> --- gcc/config/rs6000/darwin-libgcc.10.4.ver (revision 142592)
> +++ gcc/config/rs6000/darwin-libgcc.10.4.ver (working copy)
> @@ -74,3 +74,5 @@
> ___udivdi3
> ___udivmoddi4
> ___umoddi3
> +___emutls_get_address
> +___emutls_register_common
>
>
>
Iain,
I am certain that the Darwin developers would reject such a change.
The versioned symbols presented in libgcc_s.10.4.dylib and in
libgcc_s.10.5.dylib are supposed to be fixed upon release of the
that versioned libgcc in the matching OS release. The contents of
those two shared libraries are not supposed to diverge from those
shipped by Apple with its OS releases. I think what you want to do
make sure you are using the FSF libgcc's and not the system ones
while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter
step will cause the unversioned libgcc to be used with all the newer
symbols specific to the FSF gcc 4.4 release (that are not listed in
the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files).
Jack
ps It might be possible for you to convince Apple to add new symbols
to the upcoming darwin 10.6 versioned libgcc but they will only
likely do that if they support the same emutls feature in their
gcc 4.2.1 compiler.
