RE: Relocation of SDK

[Daniel Machon <dama@universal-robots.com>]

[-- 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 --]