[Buildroot] [RFC PATCH 2/9] support/scripts: add fix-rpath script to sanitize the rpath

[Wolfgang Grandegger]

Am 12.03.2017 um 21:53 schrieb Arnout Vandecappelle:
>
>
> On 08-03-17 10:25, Wolfgang Grandegger wrote:
>> Am 07.03.2017 um 18:40 schrieb Arnout Vandecappelle:
>>>
>>>
> [snip]
>>>  So in that case we can't skip share. We certainly can skip include, I think,
>>> though the benefit is perhaps limited.
>>>
>>>  Of course, if the entire staging can be skipped it's even easier :-)
>>
>> Yep.
>
>  I propose that you start with the simple option, but don't do it for staging
> for the time being. Until Samuel comes with an argument why staging is necessary :-)
>
> [snip]
>>>> "patchelf --make-relative" will drop the rpath above, because the first
>>>> two needed libs are not in the listed rpath but in
>>>> "host/usr/x86_64-buildroot-linux-gnu/lib64".
>>>
>>>  That's the staging dir - it should certainly NOT use anything from there.
>>
>> No, the staging dir is "host/usr/x86_64-buildroot-linux-gnu/sysroot/".
>
>  My bad. Still, it's a cross-directory. It contains libgcc and other stuff from
> the cross-compiler. So it is NOT meant to be used by the host binaries.
>
>  It's easier to see when you do actual cross-compilation, then you'll see the
> binaries there are for the target, not the host.
>
>
>>
>>>> Running patchelf with "LD_DEBUG" tells me that it will take the libraries
>>>> from the host (/usr/lib). Just wondering if that's correct!?
>>>
>>>  Yes it's correct, those 3 libraries are standard host libraries that can be
>>> found in the standard paths.
>>
>> Hm, what are the libraries in "host/usr/x86_64-buildroot-linux-gnu/lib64" then
>> good for? They work if I use "LD_LIBRARY_PATH" to run the executable.
>
>  Since your target is x86_64, just like your host, running a target binary will
> just work as long as it can find the libraries (i.e. as long as you set
> LD_LIBRARY_PATH).
>
> [snip]
>>>  To be evaluated if the speedup from using cmp is worth the false positives.
>>
>> I wrote a little C program just checking the first 4 bytes of the file. The
>> saving is 19 vs. 22 seconds. With "readelf" I have similar results.
>
>  You mean 19 seconds for the C program vs 22 seconds for cmp? That's what I
> would expect indeed because cmp basically does the same. In my measurements,
> readelf still was significantly slower - I didn't write down the numbers but
> from memory it was like 25%.

No, 19 sec for the C program just checking the first 4 bytes. 22 with 
patchelf. And with readelf I think it was close to 19 sec as well. I 
will doublecheck, though.

>
>> patchelf is
>> written in C++... maybe that's the reason why it's slower.
>
>  Well, it's rather because patchelf reads the entire file into a std::vector,
> while readelf will just seek to the bits that are requested.
>
>
>
>  By the way, did you already post your patches to the patchelf list?

I'm currently preparing a new patch series. I did not find a mailing 
list for the patchelf project. Maybe I have to use the GIT hub interface.

Wolfgang.