libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)

Steve Kargl <sgk_at_troutmask.apl.washington.edu>:


[...]
> Sigh.  Adding USE_GCC isn't the solution.
>
> % pan
> Segmentation fault (core dumped)
> % ldd /usr/local/bin/pan | grep ++
>         libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000)
>         libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000)
>
> This can't be good.  And, unfortunately, testing math/octave shows
> no better :(
>
> % octave
> Segmentation fault (core dumped)
> % ldd /usr/local/bin/octave-3.6.4 | grep ++
>         libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000)
>         libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000)
>

This brings up another point into which I am running with the previously
discussed blender issue.

Let's assume port A_defcompiler does not specify a compiler and c++ lib, it
will default to libc++ and clang++ on 10.x or newer, correct?
If now a port B_gnuish depends on port A_defcompiler, but at the same defines
GCC + libstdc++, the resulting binary might link against libc++ and libstdc++
at the same time. This in turn makes the port unusable. The same applies
to the other way around.

Right now we do not have mechanism to detect and handle those flaws.  
Maintainers
might be even less aware of those issues. Does anyone know a proper  
way to deal
with this at the moment on 10.x+ or is this something that was missed  
until now?

Cheers
Marcus