Building specific ports with gcc in 10.0

[Matthieu Volat]

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
> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20131203/f87c2fa5/attachment.sig>