Relocation of SDK

Relocation of SDK

[Daniel Machon]

[-- Attachment #1.1: Type: text/plain, Size: 2236 bytes --]

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.

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.

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.

Best regards,
Daniel

Med venlig hilsen / Best regards

Daniel Machon
Embedded Linux Engineer
R&D Department
[cid:UR_New_Logo_266cf885-8c99-4fe9-bae0-ff88fedf0005.png]

Universal Robots A/S
Energivej 25
5260 Odense S

Phone: +45 89 93 89 89
Cell: +45 27 99 72 32

dama@universal-robots.com<mailto:dama@universal-robots.com>
www.universal-robots.com<http://www.universal-robots.com>



Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.

If Universal Robots A/S processes personal data relating to physical persons, such processing will meet the requirements of applicable data protection legislation.Please see our Privacy Policy here.<https://www.universal-robots.com/about-universal-robots/privacy-policy/>


[-- Attachment #1.2: Type: text/html, Size: 5501 bytes --]

[-- Attachment #2: UR_New_Logo_266cf885-8c99-4fe9-bae0-ff88fedf0005.png --]
[-- Type: image/png, Size: 3508 bytes --]

Re: Relocation of SDK

[Baurzhan Ismagulov]

On Sat, Feb 20, 2021 at 09:31:34PM +0000, Daniel Machon wrote:
> 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).

I agree that chroot / nspawn / ... into the SDK is a useful feature and we
should keep it working.


> 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.

We had tried that and it didn't work:

https://groups.google.com/g/isar-users/c/sjqTLpw4KTE/m/Ro9aLnGZAQAJ

So, the current way is to run the script to undo the relocations, chroot, then
create the relocations again. If you try this, please let us know whether it
works. IIRC, during the remove the script puts some replacement relocations
into the binaries, while the original binaries don't have any -- but that
should work.

Otherwise, one has probably to rebuild the SDK with updated SDK_PREINSTALL /
SDK_INSTALL. Not sure how that works for the existing packages not coming from
Debian.


With kind regards,
Baurzhan.

Re: Relocation of SDK

[Jan Kiszka]

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

RE: Relocation of SDK

[Daniel Machon]

[-- Attachment #1.1: Type: text/plain, Size: 4748 bytes --]



>

Med venlig hilsen / Best regards

Daniel Machon
Embedded Linux Engineer
R&D Department
[cid:UR_New_Logo_266cf885-8c99-4fe9-bae0-ff88fedf0005.png]

Universal Robots A/S
Energivej 25
5260 Odense S

Phone: +45 89 93 89 89
Cell: +45 27 99 72 32

dama@universal-robots.com<mailto:dama@universal-robots.com>
www.universal-robots.com<http://www.universal-robots.com>



Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.

If Universal Robots A/S processes personal data relating to physical persons, such processing will meet the requirements of applicable data protection legislation.Please see our Privacy Policy here.<https://www.universal-robots.com/about-universal-robots/privacy-policy/>


-----Original Message-----
> From: isar-users@googlegroups.com <isar-users@googlegroups.com> On
> Behalf Of Baurzhan Ismagulov
> Sent: 22. februar 2021 10:03
> To: isar-users@googlegroups.com
> Subject: Re: Relocation of SDK
>
>
> CAUTION - EXTERNAL EMAIL: Do not open attachments or links unless you
> recognize the sender and the content is safe.
>
>
> On Sat, Feb 20, 2021 at 09:31:34PM +0000, Daniel Machon wrote:
> > 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).
>
> I agree that chroot / nspawn / ... into the SDK is a useful feature and we
> should keep it working.
>
>
> > 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.
>
> We had tried that and it didn't work:
>
> https://groups.google.com/g/isar-users/c/sjqTLpw4KTE/m/Ro9aLnGZAQAJ

[Daniel Machon]
I see, but why even change the interpreter and RPATH of any binaries that should not be run on the host machine in the first place. The SO post is about patching the interpreter of 'grep' with $ORIGIN - obviously that doesn't work - but then again, in this case we don't really want to patch grep in the first place.

I get there are 2 separate use-cases for the SDK:
1) Relocate the SDK and use the cross-toolchain from the host (chroot will now not work)
2) Restore the SDK and use the chroot to build.

What I was looking for was:
1) Relocate the SDK and use the toolchain from the host (chroot *still*works, toolchain does not work inside chroot)
2) Restore the SDK and use the chroot to build.

I think this could be accomplished by:

- Patching interpreter of all x86_64-linux-gnu-* only. No need to patch RPATH.
- If you need other binaries to run on the host (gdb, clang etc.), that require libraries, that themselves need patching: patch the interpreter of the binary (no $ORIGIN) and patch the RPATH of the library using $ORIGIN.

I get that a container SDK is coming (looking forward to this), but I think that a traditional toolchain experience is much easier to integrate with your IDE for developers. This is one of the reasons for trying to get the SDK running in this way.

- relocate the SDK and use the cross-toolchain while still being able to use chroot.
- still use the SDK as a chroot if you restore the chroot again.

> So, the current way is to run the script to undo the relocations, chroot, then
> create the relocations again. If you try this, please let us know whether it
> works. IIRC, during the remove the script puts some replacement
> relocations into the binaries, while the original binaries don't have any --
> but that should work.
>
> Otherwise, one has probably to rebuild the SDK with updated
> SDK_PREINSTALL / SDK_INSTALL. Not sure how that works for the existing
> packages not coming from Debian.
>
>
> With kind regards,
> Baurzhan.
>
> --
> You received this message because you are subscribed to the Google
> Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/isar-
> users/20210222090319.GJ20742%40yssyq.m.ilbers.de.

[-- Attachment #1.2: Type: text/html, Size: 6840 bytes --]

[-- Attachment #2: UR_New_Logo_266cf885-8c99-4fe9-bae0-ff88fedf0005.png --]
[-- Type: image/png, Size: 3508 bytes --]