[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

[jeremyhu at macports dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806

--- Comment #16 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 17:47:52 UTC ---
(In reply to comment #14)
> Interestingly Macports' libgomp shows the same expected emutls related symbols
> as fink...
> 
> % nm libgomp.1.dylib  | grep emutls
>                  U ___emutls_get_address
> 000000000000b1e0 d ___emutls_v.gomp_tls_data
> 
> I suspect the absence of ___emutls_v.* symbols in the MacPorts gcc47's
> libstdc++.6.dylib could be due to the fact that clang is used to build it
> rather than a proper full bootstrap. Please try restoring the bootstrap and see
> if the symbols are restored to libstdc++.6.dylib.

We do a full bootstrap first before building libstdc++.  There is an issue with
clang (fixed in llvm-3.2) which prevents us from using clang to build libstdc++

(In reply to comment #15)
> I believe your no-runtime-stubs.patch used during the initial build of
> libstdc++ is at fault...
> ...
> 
> These changes will certainly keep config.h in the libstdc++-v3 build directory
> from having...
> 
> #define HAVE_TLS 

Why?  That seems odd.

> Why is it so critical for MacPorts to eliminate the linkage on 
> libgcc_ext.10.4/ libgcc_ext.10.5?

Because it doesn't exist.