[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

Wolfgang Grandegger wg at grandegger.com
Wed Jun 28 06:45:10 UTC 2017


Am 28.06.2017 um 00:47 schrieb Arnout Vandecappelle:
> 
> 
> On 22-06-17 08:37, Wolfgang Grandegger wrote:
>> Hello Arnout,
>>
>> Am 21.06.2017 um 23:03 schrieb Arnout Vandecappelle:
>>>    Hi Wolfgang,
>>>
>>> On 21-06-17 09:59, Wolfgang Grandegger wrote:
>>>> Hello,
>>>>
>>>> this topic is still pending... some more input below...
>>>>
>>>> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>>>>> Hello Arnout,
>>>>>
>>>>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>>>>
>>>>>>
>>>>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
> [snip]
>>>>>>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>>>>>>     files in the target tree. "/lib" and "/usr/lib" have been removed
>>>>>>>     already.
>>>>>>
>>>>>>    Good point, I don't think we want that... Neither for the ones in staging, I
>>>>>> suppose. The RPATHs there should all be absolute paths which should be
>>>>>> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
>>>>>
>>>>> Could be done, no problem. Just requires some further modifications to
>>>>
>>>> I just learned that using relative path for the target breaks "sudo", at least.
>>>
>>>    So if you change sudo's RPATH to $ORIGIN/../libexec/sudo it doesn't find
>>> libsudo_util.so.0 at runtime? Or how does it break?
>>
>> Yep, that's the problem. I think it's because of "For security, the
>> dynamic linker does not allow use of $ORIGIN substitution sequences for
>> set-user and set-group ID programs..." from
>>
>>    http://seclists.org/fulldisclosure/2010/Oct/257
> 
>   Ah I see. So in target we should always use absolute paths. Makes sense.
> 
> [snip]
>>>>>>    I'm not entirely sure about staging, whether ld will use RPATH as an
>>>>>> alternative to -L and in that case whether it is done relative to sysroot or
>>>>>> not.
>>>>>
>>>>> So far, the patch series works for me very well. Just my usecase, of course.
>>>
>>>    IIRC I checked a while ago and it looked like ld would use RPATH as a link path
>>> (i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
>>> Which means that we shouldn't make the RPATHs in staging relative to
>>> STAGING_DIR, otherwise it may pick up the library from the host. This really
>>> shouldn't happen because the link normally should get the appropriate -L flag to
>>> find the target lib and the -L has precedence over RPATH, but better be safe.
>>
>> The man page of "ld" says:
>>
>> "The linker uses the following search paths to locate required shared libraries:
>>   ...
>>   6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are
>>       searched for shared libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries
>>       exist."
> 
>   But this doesn't clarify if these paths are interpreted relative to --sysroot
> or not.

I'm going to check what is in the orogilan rpath. I guess that the 
pathes are absolute to the host.

>>
>> Then we should use $ORIGIN relative to the ELF file for the staging tree
>> (like for the host tree) to make it relocatable.
> 
>   That is for sure the safest option.

BTW, like for the target, /lib and /usr/lib is removed from the rpath. 
Don't know if the linker looks into sysrot/lib or sysroot/usr/lib by 
default.

> [snip]
>>>>>>> Things not yet addressed:
>>>>>>>
>>>>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>>>>     to the build system (in ELF and text files).
>>>>>>
>>>>>>    A solution to this (and other problems) is to use the same approach as
>>>>>> check-bin-arch: do it as an instrumentation hook for each package, and only look
>>>>>> at the files added by that package. That way, the overhead is spread out over
>>>>>> the entire build process, and doing rebuilds doesn't run patchelf on all files
>>>>>> anymore in the finalize step.
>>>>>
>>>>> This is just to solve the issue mentioned above or a general approach (instead
>>>>> of doning rtpath sanitation at the end)?
>>>>
>>>> Any opinions here?
>>>
>>>    Preferably as an instrumentation hook, because:
>>> - it speeds things up dramatically if you do 'make foo-rebuild';
>>> - things are still correct if you interrupt the build in the middle;
>>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>>> and then you rebuild a package, the RPATH in the libs you link with is different
>>> than the first time you built it).
>>
>> OK, as I see it, check-bin-arch is only for the files in the target tree. Having a
>> closer look now.
> 
>   Yes, for this approach to work the packages-file-list has to be extended to
> cover host and staging as well. And since host includes staging, the find
> command for host is a little complicated.

With that approach we do not need "find" any longer. There will by a 
list of installed files per package.

>>>>> How should I go ahead to get this patch series accepted sooner than later? We
>>>>> could make the option configurable, for example, to reduce the risk of
>>>>> breaking something.
>>>>
>>>> Is a relocatable SDK still on the wish list? How should/could I proceed to get
>>>> the feature accepted sooner than later?
>>>
>>>    You should pray that someone takes the time to continue the review :-)
>>>
>>>    Occasionally drawing attention to the series like you do know definitely helps.
>>
>> OK, more soon...
> 
>   Next week in the Buildroot Summer Camp I'm going to spend time on this series,
> so there should be progress...

OK, thanks.

Wolfgang.


More information about the buildroot mailing list