[MacPorts] #56616: flac: stdlibc++ mismatch

[MacPorts]

#56616: flac: stdlibc++ mismatch
---------------------+-------------------------
  Reporter:  iEFdev  |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.5.2
Resolution:          |   Keywords:  cxx_stdlib,
      Port:  flac    |
---------------------+-------------------------

Comment (by ryandesign):

 Ken replied while I was writing this reply, but here it is:

 Aha—the log shows it's using llvm-gcc-4.2 (or rather llvm-g++-4.2) which
 does not support libc++. Only clang supports libc++. gcc-4.0, gcc-4.2,
 apple-gcc-4.2, and all the FSF GCC versions don't support libc++ either.

 I'm not sure what the correct fix is.

 We could modify this port and all other ports that use C++ to blacklist
 non-clang compilers. Identifying those ports is a bit of work, and it
 would unnecessarily exclude those compilers on systems that use libstdc++,
 where non-clang compilers would work fine.

 Or we could modify base to remove non-clang compilers from the list of
 possible compilers when `configure.cxx_stdlib` is libc++. But that would
 unnecessarily exclude those compilers from ports that don't use C++, where
 those compilers would work fine.

 The problem is that the default list of compilers and the blacklist that
 ports can apply to it has to do with a compiler ''collection'', which
 usually includes a C compiler, a C++, compiler, an Objective-C compiler,
 an Objective-C++ compiler, and a C preprocessor, and sometimes other
 compilers like Java or Fortran compilers. And now what we want to do is
 impose additional restrictions only on the C++ compiler (and Objective-C++
 compiler) parts of that collection. The code in portconfigure.tcl that
 builds up the default list of compilers is probably the place where these
 changes would have to happen.

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