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: Sat, 06 Oct 2012 21:14:30 +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 #21 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 21:14:30 UTC ---
(In reply to comment #19)
> (In reply to comment #18)
> > 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.
>
> My understanding is that the libgcc symbols that have been subsumed into
> libSystem as of
> darwin10 and will always override those provided by any additional libgcc.
yes
> The
> following messages
> from the darwin linker developer on llvm-dev covered this and related issues
> with the unwinder.
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html
>
> Perhaps you are proposing that eventually we gut the duplicate symbols, now in
> libSystem, out of FSF libgcc_s but that would have to be done very carefully.
> Over
> a years work went into the libgcc_ext design and implementation. A similar
> effort
> would be required to gracefully replace it.
Yes ... which is why I simply mentioned it in a comment and haven't started
going down that road except as a brain exercise.