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.
