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

On Wed, Nov 13, 2013 at 12:52:16PM -0500, Ryan Stone wrote:
> On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen <mva_at_freebsd.org> wrote:
> > 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?
> 
> How different is this from the previous situation?  As I understand it
> previously A_defcompiler would be linked against the system libstdc++
> and B_gnuish would be linked against the gccXX port libstdc++.  In my
> experience libstdc++ does not have good ABI stability between versions
> so shouldn't you have the same potential for problems?

I haven't seen a problem with mixing the system's libstdc++ with
a version from lang/gcc46.  I can assure you that the problem
is very really with libc++ vs libstdc++ within the ports collection.
To getting working news/pan and math/octave, I had to recompile
graphics/graphite2, graphics/libGL, graphics/libGLU, and
x11-toolkits/fltk with "USE_GCC=any" to avoid the conflict. 
Fortunately, I have only another 360 installed ports to check for
the conflict.

-- 
Steve