Building specific ports with gcc in 10.0
mazhe at alkumuna.eu
Tue Dec 3 09:25:47 UTC 2013
Le 3 déc. 2013 à 00:00, Matthias Andree <matthias.andree at gmx.de> a écrit :
> Signé partie PGP
> 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:
> > libdarktable.so: 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&)'
> > libdarktable.so: undefined reference to `Exiv2::XmpParser::encode(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, Exiv2::XmpData const&, unsigned short, unsigned int)'
> > libdarktable.so: 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
Thanks, giving up on OpenMP in this case (and praying that no other c++ port will trigger this problem) was also my conclusion… That or begin with installing gcc from ports and then using it as port compiler, but I've grown to like clang :)
One other possible solution would be to manage having gcc to not use its c++ header/libstdc++, but the base headers and libc++. I see that one debian developer seems to achieved that (http://sylvestre.ledru.info/blog/2012/08/15/libc_new_c_standard_library_in_debian).
> 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.
There were some news a while ago that it was updated to clang 3.3 and the llvm project seems to like the idea as they put it in their project list : http://openmp.llvm.org/ . The problem is that it requires the intel openmp runtime that only build with gcc/icc for now, I tried to add clang support but it's not so trivial...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the freebsd-ports