From owner-freebsd-ports@FreeBSD.ORG Mon Dec 2 23:00:47 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 362B257D for ; Mon, 2 Dec 2013 23:00:47 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D68DE129D for ; Mon, 2 Dec 2013 23:00:46 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.96.38]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MN748-1Vh0lq37Ky-006gHl for ; Tue, 03 Dec 2013 00:00:39 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id CB4A923CF4C; Tue, 3 Dec 2013 00:00:37 +0100 (CET) Message-ID: <529D1115.80400@gmx.de> Date: Tue, 03 Dec 2013 00:00:37 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Subject: Re: Building specific ports with gcc in 10.0 References: <20131113195047.628d288a@alkumuna.eu> In-Reply-To: <20131113195047.628d288a@alkumuna.eu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:47iFKgfwhKYTAMj/JmaYLUUT9A/D1j2O+wWOhbsxy1zuNYufLVk c71zN3irQVSy82q4qNnVpgo08T0Xma2BFiX1/oNXfRcAQxKtIGq1ITncnI979ozpvxFnK+2 FQCVZGCVCEOOsC1o2hWRrw6rAqkbNUu7FiAsHUv24ZwkbYi6HHlm/LRu/AEPBOl9rRZbK1y YjtcWOubJjm5/+zQCoY/Q== Cc: mazhe@alkumuna.eu, portmgr@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:00:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- 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: > > libdarktable.so: undefined reference to `Exiv2::XmpProperties::registerNs(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&)' > libdarktable.so: undefined reference to `Exiv2::XmpParser::encode(std::basic_string, std::allocator >&, Exiv2::XmpData const&, unsigned short, unsigned int)' > libdarktable.so: undefined reference to > `Exiv2::ExifData::operator[](std::basic_string std::char_traits, std::allocator > 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. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlKdERQACgkQvmGDOQUufZUdWACfdLoxiVqRy24bCjeenmY9KHFR o2UAoJncOwme+EToYzoxOJKBIVgTdNXs =VJVT -----END PGP SIGNATURE-----