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: Fri, 05 Oct 2012 17:41:16 +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
Jeremy Huddleston <jeremyhu at macports dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeremyhu at macports dot
| |org
--- Comment #8 from Jeremy Huddleston <jeremyhu at macports dot org> 2012-10-05 17:41:16 UTC ---
I don't know that we're playing "games" with which libstdc++ gcc uses at link
time. Instead of having multiple copies of libstdc++ lying around, you now
have one, and it's either built from gcc-4.8 (the libstdcxx-devel port) or from
gcc-4.7 (the libstdcxx port). It lives as ${prefix}/lib/libstdc++.6.dylib, and
is picked up by g++-mp-XX by way of their libstdc++.dylib symlinks.
Additionally, we hope to eventually move this libstdc++ on top of libc++abi
instead of libsupc++, so it can co-exist with the host libc++ and libstdc++ in
the same address space (users seem to do mixing of the C++ runtimes which is
what instigated the libstdcxx port to begin with).
As for the no-runtime-stubs.patch patch, that is *NOT* used to build gcc47.
That is only used in the process of building libstdc++.6.dylib in the libstdcxx
port, and it is done in order to intentionally not have the resulting
libstdc++.dylib link against the libgcc runtime dynamically. The gcc
buildsystem is so convoluted that this seemed to be the easiest way to ensure
that the resulting libstdc++.dylib picked up its gcc runtime statically.