#38500: gcc48: stable 4.8.0 released -----------------------+------------------- Reporter: larryv@… | Owner: mww@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gcc48 | -----------------------+------------------- Comment (by howarth@…): Replying to [comment:19 jeremyhu@…]:
Replying to [comment:18 howarth@…]:
Replying to [comment:17 jeremyhu@…]:
That patch from #38758 does some incorrect things to libstdcxx. Those are not the desired changes for libstdcxx, and the issue they are trying to fix is independent of the version bump.
Exactly what is being done incorrectly?
You are installing the libgcc runtime dylibs as well.
Yes because your current usage of -static-libgcc for linking the libstdc++ shared lib is quite broken. We ran into a very similar issue with the libitm shared library which revealed that the faster c++ weak-symbol coalescing introduced in darwin10 plays havoc with symbol resolution for shared libs that have static libs linked in. Let me explain in more detail. If you have the same non-weak symbols in both libSystem and in the static libgcc, linking a shared library which uses those symbols against the static libgcc insures that the symbols from the static lib are always used). The faster c++ weak symbol coalescing is quicker because it only attempts to find alternative symbols outside of the code module from shared libraries if those symbols are marked as weak in the shared libs. It is pretty hairy stuff and took us a long time to wrap our heads around to fix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 in FSF gcc 4.8.0. The final solution was effectively the same (avoid linking in static libs).
Please keep these comments in a separate ticket. It's difficult
tracking your issues across multiple unrelated tickets.
the only one that works reliably is to build both c and c++ with a
full bootstrap
Then just try reverting r103047 (#36116). Don't do the other changes.
I can do it but I know it won't fix the test case that tickles the use of two unwinders. You are still linking in a libgcc_eh.a and trying accessing non-weak symbols from libSystem (which will never be used due to the faster c++ weak coalescing). Just ask Nick Kledzik if you don't believe me. He helped us understand the subtly in this change made at darwin10. I know you want this magically fixed in FSF's libgcc_eh but it ain't gonna happen. The whole issue becomes devilishly complex on darwin because of the fact that many of the calls in libgcc have been subsumed into libSystem. For llvm, life is simpler because the same compiler-rt code used for those calls in clang/llvm are used in libSystem. For FSF gcc, we have a fork and it is better to focus on the quality of the shared libgcc support (where we can use stubs to only provide those calls which libSystem doesn't). -- Ticket URL: <https://trac.macports.org/ticket/38500#comment:20> MacPorts <http://www.macports.org/> Ports system for OS X