Le 3 déc. 2013 à 00:00, Matthias Andree <[email protected]> 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 > realizable. 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...
signature.asc
Description: Message signed with OpenPGP using GPGMail
