lang/gjs and lang/spidermonkey24 are currently built with
USES=compiler:c11. On FreeBSD 8, this causes them to be
compiled with clang from ports, and on FreeBSD 9, they are
built with clang from base. In both cases, they are linked
to libstdc++ from base.
These two ports are dependencies of x11-fm/sushi, which also
depends on webkit-gtk3, which is compiled with
USES=compiler:c++11-lib. On FreeBSD 8 and 9 webkit-gtk3 is
compiled with gcc from ports and linked to its newer bundled
libstdc++. Sushi is compiled with gcc from base and consists
of pure C code, so it does not link directly to libstdc++.
The build fails because ld links in the base version of libstdc++
before it links in webkit-gtk3, and then discovers that the
newer libstdc++ ABI needed by webkit-gtk3 is missing.
Converting sushi to USES=compiler:c++11-lib does not fix
the build failure, and just changes the error message, probably
because sushi does not directly link to any version of libstdc++.
If sushi is further hacked to force it to link directly to the
newer version of libstdc++ bundled with the gcc port, the build
succeeds, but the resulting executable segfaults inside libstdc++
with a stack trace that traverses a bunch of functions contained
in the gjs and spidermonkey24 libraries.
Converting gjs and spidermonkey24 to USES=compiler:c++11-lib
forces them to be compiled with the ports version of gcc on
FreeBSD 8 and 9 and link to its bundled libstdc++ (and is a no-op
on FreeBSD 10 and higher). Because these libraries are linked
into sushi before webkit-gtk3, they load the version of libstdc++
which meets the requirements of webkit-gtk3, and the resulting
executable is functional. No modifications to sushi are necessary.
See:
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196078> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199434> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199435>
MFH: 2015Q2 ?