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.
