public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Daniel Machon <dama@universal-robots.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Relocation of SDK
Date: Sat, 20 Feb 2021 21:31:34 +0000	[thread overview]
Message-ID: <febaf55bc1d644deb4bab63c331910cb@universal-robots.com> (raw)


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

             reply	other threads:[~2021-02-20 21:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20 21:31 Daniel Machon [this message]
2021-02-22  9:03 ` Baurzhan Ismagulov
2021-02-22 11:01   ` Daniel Machon
2021-02-22  9:41 ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=febaf55bc1d644deb4bab63c331910cb@universal-robots.com \
    --to=dama@universal-robots.com \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox