[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

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.