Steve Kargl <>:

Sigh.  Adding USE_GCC isn't the solution.

% pan
Segmentation fault (core dumped)
% ldd /usr/local/bin/pan | grep ++ => /usr/local/lib/gcc46/ (0x3c52bf000) => /usr/lib/ (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 ++ => /usr/local/lib/gcc46/ (0x3c92ec000) => /usr/lib/ (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?


_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to