Re: Relocation of SDK

[Jan Kiszka <jan.kiszka@siemens.com>]

On 20.02.21 22:31, Daniel Machon wrote:
>
> Hi,
>
>  
>
> I have been working with the SDK lately, and came across a rather
> unfortunate side-effect of the relocation of the SDK.
>
>  
>
> When the SDK is relocated, the interpreter and the RPATH of **ALL**
> the binaries are changed to that of the host system. This means that a
> developer can not longer chroot into the SDK.
>

Right - but then don't relocate in the first place.

>  
>
> I would argue, that a common development workflow would be to use the
> cross-toolchain provided by the SDK, and then chroot into the SDK to
> install dependencies (we have the possibility of installing multiarch
> packages). This is currently not possible, because the interpreter and
> the RPATH is change for all the binaries of the SDK.
>

You can add missing packages upfront, see SDK_* variables. This is
superior anyway because an SDK is a snapshot that may have a hard time
still finding fitting dependencies that weren't included at build time.

>  
>
> Why not only change the interpreter and RPATH of the cross-toolchain
> binaries? These are the binaries that are meant to be run on the host
> anyway.
>
> If you need to change the RPATH of any libraries (I came across this
> need when trying to make gdb available to the host), you can make
> RPATH relative using $ORIGIN.
>

As Baurzhan commented, this is not that easy.

I think we have two clearly different use cases than can be derived from
the same SDK tarball - but not run at the same time.

Also note that there will be a better alternative to privileged chroots:
SDK container images. See patches on the list.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux