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

[Zac Medico]

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.
>
>
> yellow tmp # cat test.cpp
> #include <iostream>
> using namespace std;
> int main() { cout << "hello owrld" << endl ; }
>
> yellow tmp # gcc-config -l
>  [1] x86_64-pc-linux-gnu-4.7.3 *
>  [2] x86_64-pc-linux-gnu-4.7.3-hardenednopie
>  [3] x86_64-pc-linux-gnu-4.7.3-hardenednopiessp
>  [4] x86_64-pc-linux-gnu-4.7.3-hardenednossp
>  [5] x86_64-pc-linux-gnu-4.7.3-vanilla
>  [6] x86_64-pc-linux-gnu-4.8.3
>  [7] x86_64-pc-linux-gnu-4.8.3-hardenednopie
>  [8] x86_64-pc-linux-gnu-4.8.3-hardenednopiessp
>  [9] x86_64-pc-linux-gnu-4.8.3-hardenednossp
>  [10] x86_64-pc-linux-gnu-4.8.3-vanilla
>
> yellow tmp # g++ -o go test.cpp
>
> yellow tmp # ldd go
>     linux-vdso.so.1 (0x0000033f63717000)
>     libstdc++.so.6 =>
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x0000033f631cf000)
>     libm.so.6 => /lib64/libm.so.6 (0x0000033f62ecb000)
>     libgcc_s.so.1 =>
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x0000033f62cb4000)
>     libc.so.6 => /lib64/libc.so.6 (0x0000033f628f8000)
>     /lib64/ld-linux-x86-64.so.2 (0x0000033f634f6000)
>
> yellow tmp # g++ -Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/ -o
> go test.cpp
>
> yellow tmp # ldd go
>
>     linux-vdso.so.1 (0x0000036035212000)
>     libstdc++.so.6 =>
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x0000036034ccf000)
>     libm.so.6 => /lib64/libm.so.6 (0x00000360349cb000)
>     libgcc_s.so.1 =>
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00000360347b4000)
>     libc.so.6 => /lib64/libc.so.6 (0x00000360343f8000)
>     /lib64/ld-linux-x86-64.so.2 (0x0000036034ff1000)
>
>

If we use -rpath, then we need to decide how to encode the rpath
information for use in soname dependency resolution. For example, we can
introduce a PROVIDES_RPATH variable that the gcc ebuild will use to
export paths for use in soname dependency resolution. For libstdc++
consumers, we can introduce a corresponding REQUIRES_RPATH variable.

Instead of requiring ebuilds to explicitly set a REQUIRES_RPATH
variable, we might instead extract the information from DT_RPATH and
DT_RUNPATH sections. However, the result would probably need to be
subject to filtering by something like REQUIRES_EXCLUDE. Maybe it's
better to have explicit REQUIRES_RPATH settings.
-- 
Thanks,
Zac