From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E51F2138A87 for ; Wed, 25 Feb 2015 20:34:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 41799E0AB1; Wed, 25 Feb 2015 20:34:30 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AEED8E0AB0 for ; Wed, 25 Feb 2015 20:34:29 +0000 (UTC) Received: from [10.0.31.59] (unknown [100.42.98.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 899DA3409C7 for ; Wed, 25 Feb 2015 20:34:28 +0000 (UTC) Message-ID: <54EE31D2.6070509@gentoo.org> Date: Wed, 25 Feb 2015 12:34:26 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information. References: <54E8AF00.20305@opensource.dyc.edu> <54E8E809.8050702@gentoo.org> <54E97594.1090809@gentoo.org> <54E9779F.8010201@gentoo.org> <54EE27D9.3080306@opensource.dyc.edu> In-Reply-To: <54EE27D9.3080306@opensource.dyc.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 8020df0e-c246-4a0b-bc51-fdbd9fb7dbd1 X-Archives-Hash: 956f389f334ab528b7d2840d59de962a On 02/25/2015 11:51 AM, Anthony G. Basile wrote: > On 02/22/15 01:30, Zac Medico wrote: >> On 02/21/2015 10:22 PM, Zac Medico wrote: >>> If we put the real/canonical libstdc++.so path in the DT_NEEDED section, >>> then it will automatically work with existing soname dependency support. >> >> Actually, we'd also have to add a way for you to put the full path of >> the libstdc++.so in PROVIDES. For example: >> >> PROVIDES_ABSOLUTE="/usr/lib/gcc/*/*/libstdc++.so.6" >> > > I guess I don't understand how this would work exactly. What if someone > has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades > to gcc-4.9, removes 4.8 and then tries to build bar which is also > written in c++ and links against libfoo.so. We would have mismatching > abis. How would this catch it and trigger the correct rebuilds? If the absolute libstdc++ path is recorded in DT_NEEDED, then libfoo.so built against gcc-4.8 will break as soon as gcc-4.8 is unmerged. It's easy to see that a rebuild is needed, because the DT_NEEDED data in NEEDED.ELF.2 shows that libfoo.so is linked against gcc-4.8. The relevant part of the DT_NEEDED data is also recorded in REQUIRES (which is available during soname dependency resolution for binary packages). > Unless I'm misunderstanding your *'s in that line. Are you using > PROVIDES_ABSOLUTE as a way of recording what version of the compiler > libfoo.so was build with? No, it's for the gcc ebuild, in order to indicate that the absolute libstdc++ path should be included in PROVIDES, for the purposes of soname dependency resolution. > So that you'd have a line that says libfoo.so > links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so > that parsing that line gives 4.8.3? No, this dependency information would propagate via DT_NEEDED. Any builds that use the -std= flag would be responsible for ensuring that the absolute libstdc++ path is recorded in DT_NEEDED, rather than the plain libstdc++.so.6 soname. > Also if you had the absolute path in VDB somewhere, like in PROVIDES, > then you don't need it in the elf's rpath which would make me feel better. Yeah, the absolute path of libstdc++ will be recorded in gcc's PROVIDES, thanks to the ebuild setting the PROVIDES_ABSOLUTE variable. The absolute path of libstdc++ that libfoo.so links against will be recorded in both NEEDED.ELF.2 and REQUIRES. There's no need for rpath. -- Thanks, Zac