[MacPorts] #38732: gcc48 is broken by configure-timespec.patch

[MacPorts]

#38732: gcc48 is broken by configure-timespec.patch
------------------------+--------------------
  Reporter:  howarth@…  |      Owner:  mww@…
      Type:  defect     |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.1.3
Resolution:  fixed      |   Keywords:
      Port:  gcc48      |
------------------------+--------------------

Comment (by howarth@…):

 See [[BR]]
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
 [[BR]]
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
 [[BR]]
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html

 Also unfortunately, its not that simple as just removing -lgcc_eh from the
 linkage of libstdc++ as that will result in undefined symbols for
 ___emutls_v._ZSt11__once_call and[[BR]]
 ___emutls_v._ZSt15__once_callable when the test case is compiled with that
 build of the compiler. This is because libgcc_eh also provides emutls
 symbols.[[BR]]
 So you're pretty much stuck with...[[BR]]
 [[BR]]
 a) living with the broken exception handling in FSF libstdc++[[BR]]
 b) reverting back to a separate normally linked libstdc++ in each gcc4x
 package[[BR]]
 c) attampting to create a libgcc_s splitoff for the newest gcc4x which
 will be used by all the gcc4x packages[[BR]]
 [[BR]]
 This is an awful lot of pain for having a single libstdc++ package.[[BR]]
 [[BR]]
 ps We don't normally run into this breakage with -static-gcc because when
 passed to g++, both the static libgcc and libstdc++ are linked in.[[BR]]
 So while the wrong unwinder is used, the code doesn't break because only a
 single unwinder is used.[[BR]]
 pps Relying on static linkage on darwin has always been fringe behavior
 because Apple has always discouraged and minimized its use.

-- 
Ticket URL: <https://trac.macports.org/ticket/38732#comment:26>
MacPorts <http://www.macports.org/>
Ports system for OS X