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

[Anthony G. Basile]

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)


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]