This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]