From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable
Date: Wed, 12 Apr 2017 15:59:59 +0200 [thread overview]
Message-ID: <6799ad7b-a16e-d89e-eb73-d7d91880d341@mind.be> (raw)
In-Reply-To: <1490255693-9134-1-git-send-email-wg@grandegger.com>
On 23-03-17 08:54, Wolfgang Grandegger wrote:
> Hello,
>
> this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
> relocatable. It sanitizes the RPATH of all ELF files in the "target"
> and "host" tree using "patchelf --make-rpath-relative". I have started
> the mainlining process implementing "--make-rpath-relative" using
> GitHub pull request [1]... till now, no answer!
>
> Furthermore this patch creates the script "relocate-sdk.sh" in the top
> directory of the "host" tree allowing to relocate the SDK after it has
> been moved to a new location. It replaces the old path with the new
> one in all text files identified by "file --mime-type". The location
> is stored in "usr/share/buildroot/sdk-location".
>
> Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
> libraries. To overcome this problem, "qt5pase" now creates "qt.conf".
>
> Other Questions:
>
> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
> files in the target tree. "/lib" and "/usr/lib" have been removed
> already.
Good point, I don't think we want that... Neither for the ones in staging, I
suppose. The RPATHs there should all be absolute paths which should be
interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
I'm not entirely sure about staging, whether ld will use RPATH as an
alternative to -L and in that case whether it is done relative to sysroot or not.
>
> Things not yet addressed:
>
> - "make toolchain" creates a toolchain tree which still has references
> to the build system (in ELF and text files).
A solution to this (and other problems) is to use the same approach as
check-bin-arch: do it as an instrumentation hook for each package, and only look
at the files added by that package. That way, the overhead is spread out over
the entire build process, and doing rebuilds doesn't run patchelf on all files
anymore in the finalize step.
Regards,
Arnout
[snip]
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
next prev parent reply other threads:[~2017-04-12 13:59 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-23 7:54 [Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 01/10] package/patchelf: use most recent version as a base for rpath sanitation Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 02/10] package/patchelf: add patch for rpath sanitation under a root directory Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 03/10] support/scripts: add fix-rpath script to sanitize the rpath Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 04/10] core: sanitize RPATH in host tree at the very end of the build Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 05/10] core: sanitize RPATH in target tree at the end of the target finalization Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 06/10] support/scripts: add reloacte-sdk.sh script for SDK relocation Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 07/10] core: install relocation script and location at the end of the build Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 08/10] external-toolchain: check if a buildroot SDK has already been relocated Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 09/10] support/scripts: check-host-rpath now handles $ORIGIN as well Wolfgang Grandegger
2017-03-23 7:54 ` [Buildroot] [RFC PATCH v3 10/10] package/qt5base: provide "qt.conf" to make "qmake" relocatable Wolfgang Grandegger
2017-04-12 13:59 ` Arnout Vandecappelle [this message]
2017-04-27 9:37 ` [Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable Wolfgang Grandegger
2017-06-21 7:59 ` Wolfgang Grandegger
2017-06-21 21:03 ` Arnout Vandecappelle
2017-06-21 21:06 ` Arnout Vandecappelle
2017-06-27 10:54 ` Wolfgang Grandegger
2017-06-27 22:41 ` Arnout Vandecappelle
2017-06-28 6:51 ` Wolfgang Grandegger
2017-06-28 10:44 ` Arnout Vandecappelle
2017-06-28 10:59 ` Wolfgang Grandegger
2017-06-22 6:37 ` Wolfgang Grandegger
2017-06-27 22:47 ` Arnout Vandecappelle
2017-06-28 6:40 ` Peter Korsgaard
2017-06-28 6:45 ` Wolfgang Grandegger
2017-06-28 10:41 ` Arnout Vandecappelle
2017-06-28 10:57 ` Wolfgang Grandegger
2017-06-28 11:16 ` Arnout Vandecappelle
2017-06-28 12:36 ` Wolfgang Grandegger
2017-06-28 19:33 ` Arnout Vandecappelle
2017-06-29 6:13 ` Wolfgang Grandegger
2017-06-29 8:02 ` Wolfgang Grandegger
2017-06-30 8:50 ` Wolfgang Grandegger
2017-06-30 9:14 ` Wolfgang Grandegger
2017-06-30 10:25 ` Arnout Vandecappelle
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=6799ad7b-a16e-d89e-eb73-d7d91880d341@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/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