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: "howarth at nitro dot med.uc.edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 06 Oct 2012 19:26:49 +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
--- Comment #17 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-06 19:26:49 UTC ---
(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.
>
> > 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.