| 1 |
On 02/25/2015 11:51 AM, Anthony G. Basile wrote: |
| 2 |
> On 02/22/15 01:30, Zac Medico wrote: |
| 3 |
>> On 02/21/2015 10:22 PM, Zac Medico wrote: |
| 4 |
>>> If we put the real/canonical libstdc++.so path in the DT_NEEDED section, |
| 5 |
>>> then it will automatically work with existing soname dependency support. |
| 6 |
>> |
| 7 |
>> Actually, we'd also have to add a way for you to put the full path of |
| 8 |
>> the libstdc++.so in PROVIDES. For example: |
| 9 |
>> |
| 10 |
>> PROVIDES_ABSOLUTE="/usr/lib/gcc/*/*/libstdc++.so.6" |
| 11 |
>> |
| 12 |
> |
| 13 |
> I guess I don't understand how this would work exactly. What if someone |
| 14 |
> has gcc-4.8.3. Builds library libfoo.so which uses c++. Then upgrades |
| 15 |
> to gcc-4.9, removes 4.8 and then tries to build bar which is also |
| 16 |
> written in c++ and links against libfoo.so. We would have mismatching |
| 17 |
> abis. How would this catch it and trigger the correct rebuilds? |
| 18 |
|
| 19 |
If the absolute libstdc++ path is recorded in DT_NEEDED, then libfoo.so |
| 20 |
built against gcc-4.8 will break as soon as gcc-4.8 is unmerged. It's |
| 21 |
easy to see that a rebuild is needed, because the DT_NEEDED data in |
| 22 |
NEEDED.ELF.2 shows that libfoo.so is linked against gcc-4.8. The |
| 23 |
relevant part of the DT_NEEDED data is also recorded in REQUIRES (which |
| 24 |
is available during soname dependency resolution for binary packages). |
| 25 |
|
| 26 |
> Unless I'm misunderstanding your *'s in that line. Are you using |
| 27 |
> PROVIDES_ABSOLUTE as a way of recording what version of the compiler |
| 28 |
> libfoo.so was build with? |
| 29 |
|
| 30 |
No, it's for the gcc ebuild, in order to indicate that the absolute |
| 31 |
libstdc++ path should be included in PROVIDES, for the purposes of |
| 32 |
soname dependency resolution. |
| 33 |
|
| 34 |
> So that you'd have a line that says libfoo.so |
| 35 |
> links against /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so, so |
| 36 |
> that parsing that line gives 4.8.3? |
| 37 |
|
| 38 |
No, this dependency information would propagate via DT_NEEDED. Any |
| 39 |
builds that use the -std= flag would be responsible for ensuring that |
| 40 |
the absolute libstdc++ path is recorded in DT_NEEDED, rather than the |
| 41 |
plain libstdc++.so.6 soname. |
| 42 |
|
| 43 |
> Also if you had the absolute path in VDB somewhere, like in PROVIDES, |
| 44 |
> then you don't need it in the elf's rpath which would make me feel better. |
| 45 |
|
| 46 |
Yeah, the absolute path of libstdc++ will be recorded in gcc's PROVIDES, |
| 47 |
thanks to the ebuild setting the PROVIDES_ABSOLUTE variable. The |
| 48 |
absolute path of libstdc++ that libfoo.so links against will be recorded |
| 49 |
in both NEEDED.ELF.2 and REQUIRES. There's no need for rpath. |
| 50 |
-- |
| 51 |
Thanks, |
| 52 |
Zac |
Archives