[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 jeremyhu@…):

 Replying to [comment:26 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++

 I never suggested that.  I suggested removing the unwinding code from
 libgcc_eh since that is what you claimed introduced the conflict, but as
 shown above, it looks like libstdc++.dylib is using the libSystem
 libunwind and not anything from libgcc_eh for unwind.

 > 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]]

 Not ideal.

 > b) reverting back to a separate normally linked libstdc++ in each gcc4x
 package[[BR]]

 No, as mentioned before, that is not a possibility.

 > c) attampting to create a libgcc_s splitoff for the newest gcc4x which
 will be used by all the gcc4x packages[[BR]]

 I'd prefer to not have separate libgcc runtime as well.  I was really
 hoping to avoid that, but it's not out of the question.

 > [[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]]

 You seem to miss the point entirely... each binary would then have its
 *own* C++ runtime in this situation, and all of them would conflict, so
 libQT would have a separate C++ runtime than myQTApp, and passing objects
 between them would be a nightmare.

 > So while the wrong unwinder is used

 Are you sure about that?  As I showed above, libstdc++.dylib is resolving
 its Unwind* symbols to libSystem...

 > , the code doesn't break because only a single unwinder is used.[[BR]]

 Uh, no... multiple would (one per image)

 > pps Relying on static linkage on darwin has always been fringe behavior
 because Apple has always discouraged and minimized its use.

 Yes, which is why I don't provide a libstdc++.a in the package, but it's
 perfectly acceptable to use static archives within a single project to
 help collect and organize submodules.

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