This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12
- From: "jeremyhu at macports dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 06 Oct 2012 17:47:52 +0000
- Subject: [Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12
- Auto-submitted: auto-generated
- References: <bug-54806-4@http.gcc.gnu.org/bugzilla/>
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.