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 04:07 PM, Zac Medico wrote:
> On 02/25/2015 03:41 PM, Anthony G. Basile wrote:
>> On 02/25/15 15:38, Zac Medico wrote:
>>> 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.
>>>
>>
>> How do you get DT_NEEDED to the absolute libstdc++.so path when building?
>
> I'm not sure how we're going to accomplish that yet, but it should be
> feasible. Ideally, the build system would support it. The worst case
> would be that we would have to patch the DT_NEEDED sections after
> src_install.

Using patchelf built from git [1], I tried to patch the DT_NEEDED of a
"hello world" program:
$ cat hello.cpp
#include <iostream>
using namespace std;
int main() { cout << "Hello World!" << endl ; }
$ g++ -o hello hello.cpp
$ scanelf -qF '%a;%p;%S;%r;%n' hello
EM_X86_64;hello;;;libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6
$ ldd hello
        linux-vdso.so.1 (0x00007fff5992a000)
        libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f38f6a82000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f38f6783000)
        libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f38f656d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f38f61c7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f38f6d86000)
$ ./hello
Hello World!
$ patchelf --replace-needed libstdc++.so.6
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 hello
$ scanelf -qF '%a;%p;%S;%r;%n' hello
EM_X86_64;hello;;;/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6
$ ldd hello
Inconsistency detected by ld.so: dl-version.c: 224:
_dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
$ ./hello
Inconsistency detected by ld.so: dl-version.c: 224:
_dl_check_map_versions: Assertion `needed != ((void *)0)' failed!

Apparently the ld.so is not capable of resolving absolute paths in
DT_NEEDED. Maybe it's more practical to go with -rpath instead.

[1] https://github.com/NixOS/patchelf
-- 
Thanks,
Zac