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

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.