From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 19 08:25:29 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9E2B2DF; Tue, 19 Nov 2013 08:25:28 +0000 (UTC) Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 31D3B23CE7C; Tue, 19 Nov 2013 09:25:27 +0100 (CET) Message-ID: <528B2076.405@FreeBSD.org> Date: Tue, 19 Nov 2013 09:25:26 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: C++ ABI library incompatibilities c++/stdc++ (was: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)) References: <528A8481.9010200@FreeBSD.org> <62194A12-1B41-48F6-8434-BA2181411020@FreeBSD.org> <528A93BF.3020707@FreeBSD.org> <528A9A88.80904@FreeBSD.org> <20131119073903.GX59496@kib.kiev.ua> In-Reply-To: <20131119073903.GX59496@kib.kiev.ua> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NAl3THfvMFCmxhqccM35N6tfaEov9a9S9" Cc: freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 08:25:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NAl3THfvMFCmxhqccM35N6tfaEov9a9S9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 19.11.2013 08:39, schrieb Konstantin Belousov: > On Mon, Nov 18, 2013 at 11:54:00PM +0100, Matthias Andree wrote: >> Glib shares the fate, because it defers to std:: containers where poss= ible. >> >> A nice way would require additional work and get the linkers to compla= in >> that symbols resolve with a different, incompatible ABI. That would, >> however, require second-guessing other ABIs and namespaces, and would >> hardly be portable -- or add ABI versions into the object files and .a= >> and .so libraries, unless we already have ABI tags somewhere down deep= >> in the ELF stuff. I never checked. >=20 > The ABI there is an ABI of library, so linkers has nothing to do with > such conflict resolution. Nor should it. The only thing we could do to help is complain directly that the missing symbols are caused by attempting to linking libraries of different, incompatible ABIs. > Linker indeed could be tricked into stopping the linking if libstdc++ > is linked into libc++-using binary. This can be hacked together with > linker script for libc++ and use of ASSERT() and DEFINED() functions. >=20 > But the right solution for the port troubles is to just switch to > consistently use (newest) gcc for ports. I assume that Uses/compiler.mk= > finally allows to do this from the make.conf ? Anybody could share a > working incantation to put there ? That is not a solution, but an unnecessary limitation. We should make it possible to install the same library for multiple ABIs. I talked with bapt/bdrewery a tiny bit on IRC yesterday, and they fear mainly the overhead of installing the dependent C++ libraries on multiple ABI versions (say, glibmm-libstdc++-2.0, glibmm-libc++-2.0, or finding better names for the ABI), but we would only need the libraries, but not the documents or binaries or shared stuff, twice. Of course we'd need to write Mk/bsd.port.mk code to pull up dependencies specific to a certain ABI for C++ ports. I won't accept the flimsy excuses "c++ is a pain anyways, we should use objC" or "c++ has always been a pain on FreeBSD" that were offered on #bsdports. We need to change that, and we've come a good way already and are almost there. I take it that as of an up-to-date gcc48 patchlevel with an up-to-date libstdc++ this combo claims full C++11 support, too, but I like the plurality and having to support multiple compilers can only raise code quality. Still I do not see why we would want to force the whole ports world away from the system's base compiler. For graphics/rawtherapee, having fixing the compile time issue in clang and pending a commit to the 10.0-RELEASE, 10-stable and HEAD branches where applicable, we're almost there. Side note: The only remaining issue is OpenMP support, and help is on its way: . --NAl3THfvMFCmxhqccM35N6tfaEov9a9S9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKLIHYACgkQvmGDOQUufZWDcgCgm/rZLcsZM/qKsyFRkBg0QJf/ kUEAn1cdSk5RMW/7Yi5CBvaGxtP7tL2N =sJwp -----END PGP SIGNATURE----- --NAl3THfvMFCmxhqccM35N6tfaEov9a9S9--