to unbreak x11-fm/sushi on FreeBSD 8 and 9.
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.
PR: 196078, 199434, 199435
Differential Revision: https://reviews.freebsd.org/D2396
Approved by: mat (mentor)
MFH: 2015Q2
c6fbbc71d8