[MacPorts] #38500: gcc48: stable 4.8.0 released

[MacPorts]

#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