www/webkit-gtk3 build broken on FreeBSD 8.4 and general c++ library conflicts

[Don Lewis]

When attempting to build webkit-gtk3 on FreeBSD 8.4, it fails like this:

  CXXLD    Programs/LLIntOffsetsExtractor
/usr/local/lib/libc++.so.1: undefined reference to `iswalpha_l'
/usr/local/lib/libc++.so.1: undefined reference to `wctob_l'
/usr/local/lib/libc++.so.1: undefined reference to `snprintf_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswprint_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswlower_l'
/usr/local/lib/libc++.so.1: undefined reference to `mbrtowc_l'
/usr/local/lib/libc++.so.1: undefined reference to `towlower_l'
/usr/local/lib/libc++.so.1: undefined reference to `mbsrtowcs_l'
/usr/local/lib/libc++.so.1: undefined reference to `tolower_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswxdigit_l'
/usr/local/lib/libc++.so.1: undefined reference to `strxfrm_l'
/usr/local/lib/libc++.so.1: undefined reference to `strftime_l'
/usr/local/lib/libc++.so.1: undefined reference to `toupper_l'
/usr/local/lib/libc++.so.1: undefined reference to `isxdigit_l'
/usr/local/lib/libc++.so.1: undefined reference to `wcsxfrm_l'
/usr/local/lib/libc++.so.1: undefined reference to `__mb_cur_max_l'
/usr/local/lib/libc++.so.1: undefined reference to `newlocale'
/usr/local/lib/libc++.so.1: undefined reference to `iswdigit_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswctype_l'
/usr/local/lib/libc++.so.1: undefined reference to `mbrlen_l'
/usr/local/lib/libc++.so.1: undefined reference to `btowc_l'
/usr/local/lib/libc++.so.1: undefined reference to `wcrtomb_l'
/usr/local/lib/libc++.so.1: undefined reference to `mbsnrtowcs_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswcntrl_l'
/usr/local/lib/libc++.so.1: undefined reference to `localeconv_l'
/usr/local/lib/libc++.so.1: undefined reference to `asprintf_l'
/usr/local/lib/libc++.so.1: undefined reference to `mbtowc_l'
/usr/local/lib/libc++.so.1: undefined reference to `strcoll_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswpunct_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswspace_l'
/usr/local/lib/libc++.so.1: undefined reference to `towupper_l'
/usr/local/lib/libc++.so.1: undefined reference to `iswupper_l'
/usr/local/lib/libc++.so.1: undefined reference to `wcsnrtombs_l'
/usr/local/lib/libc++.so.1: undefined reference to `freelocale'
/usr/local/lib/libc++.so.1: undefined reference to `isdigit_l'
/usr/local/lib/libc++.so.1: undefined reference to `wcscoll_l'
/usr/local/lib/libc++.so.1: undefined reference to `sscanf_l'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
GNUmakefile:40531: recipe for target 'Programs/LLIntOffsetsExtractor' failed
gmake: *** [Programs/LLIntOffsetsExtractor] Error 1
*** Error code 1

Stop in /usr/ports/www/webkit-gtk3.


which indicates that trying to use the ports version of libc++ is now
pretty much a lost cause on FreeBSD 8.4.

The webkit-gtk3 port tests OSVERSION and forces the use of clang and
libc++ from ports if it thinks that the system doesn't have clang in
base (and gets it wrong on newer systems that are configured to build
base with gcc instead of clang).  The Makefile hackery for this has the
following comment:

# We need clang + libc++ or gcc 4.7+. gcc has libstdc++ conflict between
# gcc port and base. This originates from icu

I'm assuming that this is supposed to mean that gcc 4.7+ won't work
because it will drag in the matching version of libstdc++ from the gcc
port, which will conflict with the version of libstdc++ from base that
icu is linked against, because icu is always built with the compiler
from base.  If so, I don't see how this could possibly work by using
clang and libc++ from ports because any binary that gets linked to both
libc++ and libstdc++ is pretty much guaranteed to croak when executed.

It seems to be that webkit-gtk3 needs to be compiled with gcc 4.7+, at
least on FreeBSD 8.4.  Clang might be another a possibility on FreeBSD
9.x if its libc has the necessary symbols.   To avoid the c++ library
conflict, icu needs to be compiled with the same compiler and c++
library as webkit-gtk3.  Any other ports that depend on either of these
two ports will also need to use the same same compiler and c++ library
*and* any c++ dependencies of these ports will also need to do the same,
and so forth.

Maybe the cleanest thing to do is avoid using c++ (GCC) 4.2.1 when
building any (nontrivial?) ports and force the use of a compiler from
ports instead.