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

["jeremyhu at macports dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #18 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 19:53:25 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> > > These changes will certainly keep config.h in the libstdc++-v3 build directory
> > > from having...
> > > 
> > > #define HAVE_TLS 
> > 
> > Why?  That seems odd.
> 
> Not really. The use of the no-runtime-stubs.patch patch would keep the tests
> in config/tls.m4 for working properly as it breaks the ability of the xgcc
> compiler
> from accessing the emutls support calls residing in libgcc_ext.10.4/5.

Nothing actually "resides in" libgcc_ext.10.[45].dylib ... those are stub
libraries which result in those symbols resolving to
/opt/local/lib/gccXX/libgcc_s.1.dylib.

> > > 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.
> 
> This is the wrong approach. You shouldn't be trying to gut libgcc_ext from
> libstdc++-v3 but
> rather creating an additional splitoff for libgcc_s/libgcc_ext.10.4/5 so that
> they are kept at
> the latest level.

Yes, that was what I eventually want to do, but this was the first step of that
approach.  Still, this *should* work.

Note that the libgcc_ext.10.[45] are not actually needed if we're going to be
using the libgcc runtime.  This is the whole reason why I suggest just removing
them entirely in a future release.  The whole point of those stubs is to let
let linker pick up some of the runtime from libSystem and the rest (things
added after gcc-4.2) from the in-tree libgcc_s.dylib.  If we're going to be in
the business of shipping our own compiler runtime, we don't need to let some
parts resolve to libSystem and others resolve to ours.  We should just let it
all resolve to ours.