maintainer-feedback requested: [Bug 199435] [patch] convert lang/gjs to USES=compiler:c++11-lib

[bugzilla-noreply at freebsd.org]

Don Lewis <truckman at FreeBSD.org> has reassigned Bugzilla Automation
<bugzilla at FreeBSD.org>'s request for maintainer-feedback to gnome at FreeBSD.org:
Bug 199435: [patch] convert lang/gjs to USES=compiler:c++11-lib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199435



--- Description ---
Created attachment 155578
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=155578&action=edit
patch to convert gjs to USES=compiler:c++11-lib

On FreeBSD 8 and 9, USES=compiler:c11 causes gjs to be built with clang and
linked the old version of libstdc++ in base.

The x11-fm/sushi port links to both gjs and webkit-gtk3.  On FreeBSD 8 and 9,
webkit-gdk3 must now be compiled with gcc48 from ports and linked to the
version of libstdc++ from ports.  sushi itself only appears to contain C code
and doesn't require a c++ library.  When it is linked, the linker choses
libstdc++ based on the order of the shared libraries, and ends up linking to
libstdc++ from base.  This causes the build to fail with a link error because
the base version of libstdc++ does not support the newer c++ ABI version
required by webkit-gtk3.

Even if the sushi port is hacked to link to the newer libstdc++, the
application segfaults inside a deeply nested series of libmozjs and libgjs
function calls.

See <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196078> for more detail.

Changing spidermonkey24 and gjs to USES=compiler:c++11-lib, which causes them
to be built with gcc48 and linked to its bundled libstdc++, allows the
un-modified sushi port to successfully build, and not segfault when run.

See also <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199434>