[MacPorts] #55592: libunwind @5.0.1: unrecognized command line option '-stdlib=libstdc++' with clang-3.4

[MacPorts]

#55592: libunwind @5.0.1: unrecognized command line option '-stdlib=libstdc++' with
clang-3.4
---------------------------+----------------------
  Reporter:  sideeffect42  |      Owner:  jeremyhu
      Type:  defect        |     Status:  closed
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.4.2
Resolution:  wontfix       |   Keywords:
      Port:  libunwind     |
---------------------------+----------------------

Comment (by sideeffect42):

 @jeremyhu I don't have an exhaustive list of ports that fail to build with
 clang, but I opened some tickets in the last few days for the ones I've
 stumbled across.
 Given my personal experience and what other people have reported here, I'd
 assume that there are more ports that fail to build than ones that work
 (i.e. the famous "C compiler does work: no" configure error).

 I don't want to start a GCC vs. LLVM war. In the past GCC has done a
 tremendous job for me and was zero-hassle.[[BR]]
 If there are reasons for using clang I can live with that, but at least on
 10.5.8 PPC (this is the only combination I have) clang doesn't work as has
 been noted by multiple people.

 And as you have said yourself, clang++-mp-3.4 is only a wrapper around
 g++, so what's the advantage of defaulting to a compiler that's just a
 wrapper around another compiler, and of which only an ancient version even
 runs on PowerPC?
 A compiler that does not violate language specifications and does not
 create executables with undefined behaviour does not help me if it does
 not compile.

 Since this issue is moving into a compiler-selection debate, what's the
 way to go forward here?
 Should I open a new ticket for MacPorts itself?

--
Ticket URL: <https://trac.macports.org/ticket/55592#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS