1 |
On 02/25/2015 12:01 PM, Anthony G. Basile wrote: |
2 |
> On 02/25/15 14:51, Anthony G. Basile wrote: |
3 |
>> On 02/22/15 01:30, Zac Medico wrote: |
4 |
>>> On 02/21/2015 10:22 PM, Zac Medico wrote: |
5 |
>>>> If we put the real/canonical libstdc++.so path in the DT_NEEDED |
6 |
>>>> section, |
7 |
>>>> then it will automatically work with existing soname dependency |
8 |
>>>> support. |
9 |
>>> |
10 |
>>> Actually, we'd also have to add a way for you to put the full path of |
11 |
>>> the libstdc++.so in PROVIDES. For example: |
12 |
>>> |
13 |
>>> PROVIDES_ABSOLUTE="/usr/lib/gcc/*/*/libstdc++.so.6" |
14 |
>>> |
15 |
>> |
16 |
>> I guess I don't understand how this would work exactly. What if someone |
17 |
>> has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades |
18 |
>> to gcc-4.9, removes 4.8 and then tries to build bar which is also |
19 |
>> written in c++ and links against libfoo.so. We would have mismatching |
20 |
>> abis. How would this catch it and trigger the correct rebuilds? |
21 |
>> |
22 |
>> Unless I'm misunderstanding your *'s in that line. Are you using |
23 |
>> PROVIDES_ABSOLUTE as a way of recording what version of the compiler |
24 |
>> libfoo.so was build with? So that you'd have a line that says libfoo.so |
25 |
>> links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so |
26 |
>> that parsing that line gives 4.8.3? |
27 |
>> |
28 |
>> Also if you had the absolute path in VDB somewhere, like in PROVIDES, |
29 |
>> then you don't need it in the elf's rpath which would make me feel |
30 |
>> better. |
31 |
>> |
32 |
> |
33 |
> Actually no, you'd still need rpath for the elf itslef otherwise you can |
34 |
> still link against the wrong version of libstdc++.so. Note in my |
35 |
> following example that even though I build test.cpp with 4.7.3 I still |
36 |
> wind up linking aginast 4.8.3. |
37 |
> |
38 |
> |
39 |
> yellow tmp # cat test.cpp |
40 |
> #include <iostream> |
41 |
> using namespace std; |
42 |
> int main() { cout << "hello owrld" << endl ; } |
43 |
> |
44 |
> yellow tmp # gcc-config -l |
45 |
> [1] x86_64-pc-linux-gnu-4.7.3 * |
46 |
> [2] x86_64-pc-linux-gnu-4.7.3-hardenednopie |
47 |
> [3] x86_64-pc-linux-gnu-4.7.3-hardenednopiessp |
48 |
> [4] x86_64-pc-linux-gnu-4.7.3-hardenednossp |
49 |
> [5] x86_64-pc-linux-gnu-4.7.3-vanilla |
50 |
> [6] x86_64-pc-linux-gnu-4.8.3 |
51 |
> [7] x86_64-pc-linux-gnu-4.8.3-hardenednopie |
52 |
> [8] x86_64-pc-linux-gnu-4.8.3-hardenednopiessp |
53 |
> [9] x86_64-pc-linux-gnu-4.8.3-hardenednossp |
54 |
> [10] x86_64-pc-linux-gnu-4.8.3-vanilla |
55 |
> |
56 |
> yellow tmp # g++ -o go test.cpp |
57 |
> |
58 |
> yellow tmp # ldd go |
59 |
> linux-vdso.so.1 (0x0000033f63717000) |
60 |
> libstdc++.so.6 => |
61 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x0000033f631cf000) |
62 |
> libm.so.6 => /lib64/libm.so.6 (0x0000033f62ecb000) |
63 |
> libgcc_s.so.1 => |
64 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x0000033f62cb4000) |
65 |
> libc.so.6 => /lib64/libc.so.6 (0x0000033f628f8000) |
66 |
> /lib64/ld-linux-x86-64.so.2 (0x0000033f634f6000) |
67 |
> |
68 |
> yellow tmp # g++ -Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/ -o |
69 |
> go test.cpp |
70 |
> |
71 |
> yellow tmp # ldd go |
72 |
> |
73 |
> linux-vdso.so.1 (0x0000036035212000) |
74 |
> libstdc++.so.6 => |
75 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x0000036034ccf000) |
76 |
> libm.so.6 => /lib64/libm.so.6 (0x00000360349cb000) |
77 |
> libgcc_s.so.1 => |
78 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00000360347b4000) |
79 |
> libc.so.6 => /lib64/libc.so.6 (0x00000360343f8000) |
80 |
> /lib64/ld-linux-x86-64.so.2 (0x0000036034ff1000) |
81 |
> |
82 |
> |
83 |
|
84 |
If we use -rpath, then we need to decide how to encode the rpath |
85 |
information for use in soname dependency resolution. For example, we can |
86 |
introduce a PROVIDES_RPATH variable that the gcc ebuild will use to |
87 |
export paths for use in soname dependency resolution. For libstdc++ |
88 |
consumers, we can introduce a corresponding REQUIRES_RPATH variable. |
89 |
|
90 |
Instead of requiring ebuilds to explicitly set a REQUIRES_RPATH |
91 |
variable, we might instead extract the information from DT_RPATH and |
92 |
DT_RUNPATH sections. However, the result would probably need to be |
93 |
subject to filtering by something like REQUIRES_EXCLUDE. Maybe it's |
94 |
better to have explicit REQUIRES_RPATH settings. |
95 |
-- |
96 |
Thanks, |
97 |
Zac |