Re: [gentoo-portage-dev] Pre RFC on RFC: Add compiler information to exported a Package Manger's Cached Information.

[Zac Medico <zmedico@gentoo.org>]

On 02/25/2015 12:01 PM, Anthony G. Basile wrote:
> On 02/25/15 14:51, 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?
>>
>> 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?  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?
>>
>> 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.
>>
> 
> Actually no, you'd still need rpath for the elf itslef otherwise you can
> still link against the wrong version of libstdc++.so.  Note in my
> following example that even though I build test.cpp with 4.7.3 I still
> wind up linking aginast 4.8.3.

If DT_NEEDED contains the absolute libstdc++.so path, it's guaranteed to
link against the correct version, regardless of rpath.
-- 
Thanks,
Zac