Building specific ports with gcc in 10.0

Matthias Andree matthias.andree at
Mon Dec 2 23:00:47 UTC 2013

Hash: SHA1

Am 13.11.2013 19:50, schrieb Matthieu Volat:
> Hi everybody,
> With the 10.0 release becoming more and more tangible, I tried to switch one laptop to 10.0-BETA3 and see how it would go.
> I fumbled into a problem that I have a hard time to resolve: I would like to build graphics/darktable with gcc (lang/gcc46 to be precise, through the USE_GCC system) to benefit from openmp support. 
> Here's the problem : graphics/darktable, mostly C, uses graphics/exiv2 which is written in C++, but built with clang++/libc++. So when I try to build graphics/darktable, I get errors of unresolved symbols from exiv2 library:
> undefined reference to `Exiv2::XmpProperties::registerNs(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
> undefined reference to `Exiv2::XmpParser::encode(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, Exiv2::XmpData const&, unsigned short, unsigned int)'
> undefined reference to
> `Exiv2::ExifData::operator[](std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&)'
> [...]
> I suppose this comes from symbol naming conventions between clang++/libc++ and g++/libstdc++ (wasn't C++ ABI supposed to be standard? I guess not). If I build exiv2 with g++, I can build darktable, but I feel this way of doing things will be a PITA in the future.
> Does anybody knowledgeable with gcc know how to manage those issues?

An older post, but since it's unanswered, here goes:

I'd personally avoid mixing C++ libraries with software that complex,
not only to spare myself the bloat, but also to avoid subtle crashes.

I have run into the same issue with graphics/rawtherapee, and have
"solved" it by ignoring OpenMP for now on systems that default to clang,
and use clang to build rawtherapee on those. Not sure how well it works,
haven't received feedback anywhere yet.

Solving this for good would require changes to the ports infrastructure
where a C++-based port can state "I need libstdc++ ABI versions of
library FOO and BAR", or, more generally, where:

1. multiple libraries with different C++ ABI versions can be installed
   (possibly only installing the differing ABI if there is already an
   installation, as a later refinement)

   If it required two full installations (with distinct prefix) for the
   nonce, I could live with that.

2. ports can choose to depend on a particular ABI version, per their
   compiler preference, so that rawtherapee or darktable, if they set
   USE_GCC or equivalent, will automatically depend on the libstdc++
   ABI versions of libraries, and if necessary, install them.

We may also need to build/install subpackages, or multiple packages from
the same port.  I guess with STAGEDIR this has become somewhat closer to

Side remarks:

a. We dug up three clang bugs in 10-STABLE so far. One "only" causes
excessive compile times, two cause the compiler to run out of memory.
dim@ helped dig up references, reduce the test cases to reasonable size;
these issues have all been reported upstream unless the upstream
bugtracker already knew them.

b. Apparently Intel donated OpenMP to clang back in the clang-3.1 days.
I hope that these be integrated into clang, but haven't seen much
conclusive material.
Version: GnuPG v1.4.11 (GNU/Linux)


More information about the freebsd-ports mailing list