google-sparsehash on FreeBSD 10, we should not resolve the problem that way.

Tam Nguyen Duc keimoonvie at
Thu Feb 27 04:05:49 UTC 2014

So I just updated to FreeBSD 10, and almost all of my works were broken
because of a single port: google-sparsehash. This is really
frustrating, not because
it cost me a lot time to fix a relatively simple library, but because the way
the problem was 'resolved' by the port maintainer.

One of the most critical changes from FreeBSD 9 to 10 is the switch from GCC
to Clang. For some reason, google-sparsehash refused to be compiled
with Clang, but
was fine with GCC. Perhap, this caused the port maintainer to make a
decision: made google-sparsehash depends on gcc48 and used gcc48 to compile the

And yes, it compiled fine. But then I compiled my own library with
it failed miserably because of 'tr1' problem (gcc48 still used
std::tr1 namespace, but clang has put it to the upper std namespace).
I tried compiling my lib with gcc, but it also didn't
work, because my other dependancies were all compiled with clang.

What's good about a library, if it is compilable but we can't use it?
The problem was
indeed resolved for the port maintainer, but not for me.

So, my point is: to resolve an incompatible problem, you should always
tweak the piece
to adapt with the system, not change the whole system to accept the piece.

Now, return to the problem itself. I knew that google-sparsehash does
not install any .so
file, just header files (it uses templates heavily). In fact, this
library does not need
compiling, the only thing that was compiled is the test case.

So, my 'solution' is simple. Screw the test, I do not want it anyway.
Fixing the test case
so it can be built with Clang is the job of google-sparsehash owner,
not me, and also
not the port maintainer.

TL, DR. Delete every line about "TESTS" in, automake
--add-missing, autoreconf, and it's done.

More information about the freebsd-ports mailing list