Date: Tue, 3 Dec 2013 10:25:31 +0100 From: Matthieu Volat <mazhe@alkumuna.eu> To: Matthias Andree <matthias.andree@gmx.de> Cc: freebsd-ports@freebsd.org, portmgr@FreeBSD.org Subject: Re: Building specific ports with gcc in 10.0 Message-ID: <A3C3D56A-4BC3-4969-99BF-368763A6074F@alkumuna.eu> In-Reply-To: <529D1115.80400@gmx.de> References: <20131113195047.628d288a@alkumuna.eu> <529D1115.80400@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_77B1AEC6-B796-40F0-B39B-264351463BBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 3 d=E9c. 2013 =E0 00:00, Matthias Andree <matthias.andree@gmx.de> a = =E9crit : > Sign=E9 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? > > >=20 > An older post, but since it's unanswered, here goes: >=20 > I'd personally avoid mixing C++ libraries with software that complex, > not only to spare myself the bloat, but also to avoid subtle crashes. >=20 > 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. >=20 > 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: >=20 > 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) >=20 > If it required two full installations (with distinct prefix) for = the > nonce, I could live with that. >=20 > 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. >=20 > 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=85 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_i= n_debian). >=20 >=20 > Side remarks: >=20 > 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. >=20 > 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... --Apple-Mail=_77B1AEC6-B796-40F0-B39B-264351463BBA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKdo5QACgkQ+ENDeYKZi36O/wCeLmU4XSH4vDi6ddys80qdlkQW Qf8An3ICCdcSkanh77o+rB7n8bCbQEPr =VqEU -----END PGP SIGNATURE----- --Apple-Mail=_77B1AEC6-B796-40F0-B39B-264351463BBA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A3C3D56A-4BC3-4969-99BF-368763A6074F>