Make the SDK relocatable

The patch allows to use patchelf to sanitize the rpath of the buildroot libraries and binaries using the option "--make-rpath-relative <rootdir>". Recent versions of patchelf will not built on old Debian and RHEL systems due to C++11 constructs. Therefore we stick with v0.9 for the time being.

Signed-off-by Wolfgang Grandegger <[email protected]>

Hi Wolfgang,

Quoted 5 lines · Wolfgang Grandegger

The patch allows to use patchelf to sanitize the rpath of the buildroot libraries and binaries using the option "--make-rpath-relative <rootdir>". Recent versions of patchelf will not built on old Debian and RHEL systems due to C++11 constructs. Therefore we stick with v0.9 for the time being.

Quoted 1 line

Signed-off-by Wolfgang Grandegger <[email protected]>

I still have a bunch of comments, but they're solidly in the nitpicking
category. We definitely want this series (or at least part of it) in 2017.08-rc1, so if you don't respin in time, it will be applied. In that case, however, feel free to fix my nitpicks in follow-up patches. That said:

Acked-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Quoted 7 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +1 -0

new file mode 100644
index 0000000..eda32e8
@@ -0,0 +1,52 @@
+From a365bcb7d7025da51b33165ef7ebc7180199a05e Mon Sep 17 00:00:00 2001

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch line 4

Quoted 3 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +3 -0

+From: Eelco Dolstra <[email protected]>
+Date: Mon, 19 Sep 2016 17:31:37 +0200
+Subject: [PATCH] Remove apparently incorrect usage of "static"

I was going to say: we don't really need this patch. However, we do need it
because it removes the DT_INIT symbols from needed_libs (DT_INIT points to library initialisation function, not to needed libraries...). So perhaps that bit should be added to the patch message.

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch line 13

Quoted 9 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +9 -0

+
+[Upstream-commit: https://github.com/NixOS/patchelf/commit/a365bcb7d7025da51b33165ef7ebc7180199a05e]
+Signed-off-by: Wolfgang Grandegger <[email protected]>
+
+---
+ src/patchelf.cc | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+Index: patchelf-0.9.old/src/patchelf.cc

Looks like you didn't really generate this with git-format-patch, although the
header looks like it... It's not very important, but we really like to be able to regenerate exactly the same patches with the following procedure:

cd patchelf
git checkout -b buildroot 0.9
git am ../buildroot/package/patchelf/*.patch
git format-patch -N --no-renames -o ../buildroot/package/patchelf 0.9..

[snip]

package/patchelf/0003-Add-option-to-make-the-rpath-relative-under-a-specif.patch line 5

Quoted 11 lines

package/patchelf/0003-Add-option-to-make-the-rpath-relative-under-a-specif.patch new file +5 -0

new file mode 100644
index 0000000..ed7bb12
@@ -0,0 +1,423 @@
+From af8d4a24a0ef613bdb47f0b1c3d962d59c53a4be Mon Sep 17 00:00:00 2001
+From: Wolfgang Grandegger <[email protected]>
+Date: Mon, 20 Feb 2017 16:29:24 +0100
+Subject: [PATCH] Add option to make the rpath relative under a specified root
+ directory

I'm not yet 100% satisfied with this patch, because it combines too many things
in a single bunch. However, improving it really requires a lot of additional refactoring in patchelf. And patchelf test coverage is exactly great so refactoring is tricky. And we anyway can't use the latest patchelf version. So I guess this Buildroot-specific patch is good enough.

[snip]

package/patchelf/0003-Add-option-to-make-the-rpath-relative-under-a-specif.patch line 289

Quoted 6 lines

package/patchelf/0003-Add-option-to-make-the-rpath-relative-under-a-specif.patch new file +6 -0

+@@ -1261,35 +1396,35 @@
+ void ElfFile<ElfFileParamNames>::replaceNeeded(map<string, string>& libs)
+ {
+     if (libs.empty()) return;
+-
++

The patch really shouldn't contain these whitespace fixes... (Lots more below).

Hello Arnout,

Am 19.07.2017 um 23:08 schrieb Arnout Vandecappelle:

Quoted 8 lines

Hi Wolfgang,

Quoted 5 lines · Wolfgang Grandegger

The patch allows to use patchelf to sanitize the rpath of the buildroot libraries and binaries using the option "--make-rpath-relative <rootdir>". Recent versions of patchelf will not built on old Debian and RHEL systems due to C++11 constructs. Therefore we stick with v0.9 for the time being.

Quoted 6 lines

Quoted 1 line

Signed-off-by Wolfgang Grandegger <[email protected]>

I still have a bunch of comments, but they're solidly in the nitpicking
category. We definitely want this series (or at least part of it) in 2017.08-rc1, so if you don't respin in time, it will be applied. In that case, however, feel free to fix my nitpicks in follow-up patches. That said:

OK. I will concentrate on the important (and trivial) issues.

Quoted 1 line

Acked-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Should I also add your "Acked-by" to the patchelf patches itself?

Quoted 10 lines

Quoted 10 lines

diff --git a/package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch b/package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file mode 100644
index 0000000..eda32e8

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +1 -0

@@ -0,0 +1,52 @@
+From a365bcb7d7025da51b33165ef7ebc7180199a05e Mon Sep 17 00:00:00 2001

Quoted 8 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch line 4

Quoted 3 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +3 -0

+From: Eelco Dolstra <[email protected]>
+Date: Mon, 19 Sep 2016 17:31:37 +0200
+Subject: [PATCH] Remove apparently incorrect usage of "static"

I was going to say: we don't really need this patch. However, we do need it
because it removes the DT_INIT symbols from needed_libs (DT_INIT points to library initialisation function, not to needed libraries...). So perhaps that bit should be added to the patch message.

Added to the [] comment. I think the original messages should bot be touched.

Quoted 17 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch line 13

Quoted 12 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +2 -0

+
+[Upstream-commit:

https://github.com/NixOS/patchelf/commit/a365bcb7d7025da51b33165ef7ebc7180199a05e]

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +7 -0

+Signed-off-by: Wolfgang Grandegger <[email protected]>
+
+---
+ src/patchelf.cc | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+Index: patchelf-0.9.old/src/patchelf.cc

Looks like you didn't really generate this with git-format-patch, although the
header looks like it... It's not very important, but we really like to be able to regenerate exactly the same patches with the following procedure:

Quoted 4 lines

cd patchelf
git checkout -b buildroot 0.9
git am ../buildroot/package/patchelf/*.patch
git format-patch -N --no-renames -o ../buildroot/package/patchelf 0.9..

This is generate with quilt against patchelf-0.9.tag.bz2. Will fix.

Quoted 18 lines

Hello Arnout,

Am 19.07.2017 um 23:08 schrieb Arnout Vandecappelle:

Quoted 8 lines

Hi Wolfgang,

Quoted 5 lines · Wolfgang Grandegger

The patch allows to use patchelf to sanitize the rpath of the buildroot libraries and binaries using the option "--make-rpath-relative <rootdir>". Recent versions of patchelf will not built on old Debian and RHEL systems due to C++11 constructs. Therefore we stick with v0.9 for the time being.

Quoted 6 lines

Quoted 1 line

Signed-off-by Wolfgang Grandegger <[email protected]>

I still have a bunch of comments, but they're solidly in the nitpicking
category. We definitely want this series (or at least part of it) in 2017.08-rc1, so if you don't respin in time, it will be applied. In that case, however, feel free to fix my nitpicks in follow-up patches. That said:

Quoted 5 lines

OK. I will concentrate on the important (and trivial) issues.

Quoted 1 line

Acked-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Should I also add your "Acked-by" to the patchelf patches itself?

No, not to the patchelf patches. That doesn't make sense, since it's
meaningless for upstream, and for Buildroot the ack is already in the Buildroot patch.

The Sob needs to be there because its meaning is different for the Buildroot
patch and for the package patch. For the package patch, it means "I vouch that it's OK to distribute this change under the license of the package", and the license of the package is different from the license of Buildroot.

Quoted 19 lines

Quoted 10 lines

Quoted 10 lines

diff --git a/package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch b/package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file mode 100644
index 0000000..eda32e8

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +1 -0

@@ -0,0 +1,52 @@
+From a365bcb7d7025da51b33165ef7ebc7180199a05e Mon Sep 17 00:00:00 2001

Quoted 8 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch line 4

Quoted 3 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +3 -0

+From: Eelco Dolstra <[email protected]>
+Date: Mon, 19 Sep 2016 17:31:37 +0200
+Subject: [PATCH] Remove apparently incorrect usage of "static"

I was going to say: we don't really need this patch. However, we do need it
because it removes the DT_INIT symbols from needed_libs (DT_INIT points to library initialisation function, not to needed libraries...). So perhaps that bit should be added to the patch message.

Quoted 1 line

Added to the [] comment. I think the original messages should bot be touched.

ACK that.

Quoted 22 lines

Quoted 21 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch line 13

Quoted 12 lines

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +2 -0

+
+[Upstream-commit:

https://github.com/NixOS/patchelf/commit/a365bcb7d7025da51b33165ef7ebc7180199a05e]

package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch new file +7 -0

+Signed-off-by: Wolfgang Grandegger <[email protected]>
+
+---
+ src/patchelf.cc | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+Index: patchelf-0.9.old/src/patchelf.cc

Looks like you didn't really generate this with git-format-patch, although the
header looks like it... It's not very important, but we really like to be able to regenerate exactly the same patches with the following procedure:

cd patchelf
git checkout -b buildroot 0.9
git am ../buildroot/package/patchelf/*.patch
git format-patch -N --no-renames -o ../buildroot/package/patchelf 0.9..

Quoted 1 line

This is generate with quilt against patchelf-0.9.tag.bz2. Will fix.

Ah, that makes sense as well. Again, it's not very important. Do you find using
quilt to manage package patches easier than using git?

The patch allows to use patchelf to sanitize the rpath of the buildroot libraries and binaries using the option "--make-rpath-relative <rootdir>". Recent versions of patchelf will not built on old Debian and RHEL systems due to C++11 constructs. Therefore we stick with v0.9 for the time being.

Quoted 4 lines

The patch allows to use patchelf to sanitize the rpath of the buildroot libraries and binaries using the option "--make-rpath-relative <rootdir>". Recent versions of patchelf will not built on old Debian and RHEL systems due to C++11 constructs. Therefore we stick with v0.9 for the time being.

One more thing (but that can be a completely separate follow-up patch).

Currently, in most cases, we clear the rpath completely. But patchelf also has
functionality to remove the RUNPATH entry in the dynamic section. Although this doesn't really make the file smaller (the space for the original string is kept, the old string is just overwritten with X's), removing the RUNPATH entry could speed up dynamic loading slightly. It's also just weird to see these empty RUNPATH strings when you do a readelf.

The code to do that is already there, in the rpRemove section. It's pretty
simple to factor it out.

From: Samuel Martin <[email protected]>

This commit introduces the script "fix-rpath" able to scan a tree, detect ELF files, check their RPATH and fix it in a proper way. The RPATH fixup is done by the patchelf utility using the option "--make-rpath-relative <root-directory>".

Signed-off-by Samuel Martin <[email protected]>

Signed-off-by Wolfgang Grandegger <[email protected]>

support/scripts/fix-rpath new file +12 -0

+
+	    # do not process the patchelf binary but a copy to work-around "file in use"
+	    find_args+=( "-path" "${PATCHELF}" "-prune" "-o" )
+	    cp "${PATCHELF}" "${PATCHELF}.__to_be_patched"
+
+	    sanitize_extra_args+=( "--relative-to-file" )
+	    ;;
+
+	staging)
+	    rootdir="${STAGING_DIR}"
+
+	    # ELF files should not be in these sub-directories

Quoted 9 lines

From: Samuel Martin <[email protected]>

This commit introduces the script "fix-rpath" able to scan a tree, detect ELF files, check their RPATH and fix it in a proper way. The RPATH fixup is done by the patchelf utility using the option "--make-rpath-relative <root-directory>".

Signed-off-by Samuel Martin <[email protected]>

Signed-off-by Wolfgang Grandegger <[email protected]>

Some small comments below, but again, can be fixed in follow-up patches, so

Acked-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

[snip]

support/scripts/fix-rpath line 26

Quoted 3 lines

support/scripts/fix-rpath new file +3 -0

+Description:
+
+    This script scans a tree and sanitize ELF files' RPATH found in there.

                                             ^s

support/scripts/fix-rpath line 30

Quoted 4 lines

support/scripts/fix-rpath new file +4 -0

+
+    Sanitization behaves the same whatever the kind of the processed tree,
+    but the resulting RPATH differs. The rpath sanitization is done using
+    "patchelf --make-rpath-relazive".

                                   ^t

support/scripts/fix-rpath line 40

Quoted 10 lines

support/scripts/fix-rpath new file +10 -0

+
+Arguments:
+
+    TREE_KIND	Kind of tree to be processed.
+		Allowed values: host, target, staging
+
+Environment:
+
+    PATCHELF	patchelf program to use
+		(default: HOST_DIR/bin/patchelf)

And also HOST_DIR, TARGET_DIR, STAGING_DIR, and
TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR.

[snip]

support/scripts/fix-rpath line 66

Quoted 11 lines

support/scripts/fix-rpath new file +11 -0

+    case "${tree}" in
+	host)
+	    rootdir="${HOST_DIR}"
+
+	    # do not process the sysroot (only contains target binaries)
+	    find_args+=( "-path" "${STAGING_DIR}" "-prune" "-o" )
+
+	    # do not process the external toolchain installation directory to
+	    # avoid breaking it.
+	    test "${TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR}" != "" && \
+		find_args+=( "-path" "${TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR}" "-prune" "-o" )

Since this variable isn't exported, it doesn't actually end up being used. But
I think the solution is to pass it explicitly in patch 5.

support/scripts/fix-rpath line 70

Quoted 4 lines

support/scripts/fix-rpath new file +4 -0

+
+	    for excludepath in ${HOST_EXCLUDEPATHS}; do
+		find_args+=( "-path" "${HOST_DIR}""${excludepath}" "-prune" "-o" );
+	    done

Perhaps this could be refactored into defining here:

	excludepaths="${HOST_EXCLUDEPATHS}"

and moving the loop to the generic part. It would anyway be nicer to have TARGET_EXCLUDEPATHS, for symmetry.

Quoted 21 lines

support/scripts/fix-rpath new file +20 -0

+
+	    # do not process the patchelf binary but a copy to work-around "file in use"
+	    find_args+=( "-path" "${PATCHELF}" "-prune" "-o" )
+	    cp "${PATCHELF}" "${PATCHELF}.__to_be_patched"
+
+	    sanitize_extra_args+=( "--relative-to-file" )
+	    ;;
+
+	staging)
+	    rootdir="${STAGING_DIR}"
+
+	    # ELF files should not be in these sub-directories
+	    for excludepath in ${STAGING_EXCLUDEPATHS}; do
+		find_args+=( "-path" "${STAGING_DIR}""${excludepath}" "-prune" "-o" )
+	    done
+
+	    sanitize_extra_args+=( "--no-standard-lib-dirs" "--relative-to-file" )
+	    ;;
+
+	target)

support/scripts/fix-rpath line 92

Quoted 2 lines

support/scripts/fix-rpath new file +2 -0

+	    rootdir="${TARGET_DIR}"
+	    sanitize_extra_args+=( "--no-standard-lib-dirs" "--relative-to-file" )

I thought we decided that target and staging should NOT be relative-to-file,
but should be absolute paths without rootdir? Or was this a problem for staging, because the linker would add the RUNPATH to the library search path and this would point to the system libs instead of target libs? According to the man page this should only be the case for a native linker, so not for a cross linker.

I don't really like having $ORIGIN-based rpaths in target, but it's no big deal.

Regardless, the reasoning behind the choice we make should be documented here
in comments. So for host, add something to the effect that we always want $ORIGIN-based rpaths to make it relocatable. For staging, say that we want it to be the same as target. And for target, explain the choice you made.

support/scripts/fix-rpath line 104

Quoted 2 lines

support/scripts/fix-rpath new file +2 -0

+    while read file ; do
+	# check if it's an ELF file

Indentation is inconsistent: sometimes 4 spaces, sometimes 2 spaces (inside the

case, and in the condition below). And here, you're switching from spaces to tabs!

support/scripts/fix-rpath line 105

Quoted 1 line

support/scripts/fix-rpath new file +1 -0

+	if ${PATCHELF} --print-rpath "${file}" > /dev/null 2>&1; then

It might be good to check if the file actually has a non-empty rpath. When
processing a second time, most rpaths are empty so they can be skipped.

Maybe even add another patch to patchelf to exit early and quietly with just 0
or 1 depending on rpath presence.

Am 20.07.2017 um 01:02 schrieb Arnout Vandecappelle:

Quoted 3 lines · Wolfgang Grandegger

Quoted 7 lines

support/scripts/fix-rpath line 40

Quoted 4 lines

support/scripts/fix-rpath new file +4 -0

+Environment:
+
+    PATCHELF    patchelf program to use
+        (default: HOST_DIR/bin/patchelf)

And also HOST_DIR, TARGET_DIR, STAGING_DIR, and
TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR.

PATCHELF points to the patchelf utility! Or what do you mean here?

Quoted 9 lines

support/scripts/fix-rpath line 92

Quoted 3 lines

support/scripts/fix-rpath new file +3 -0

+    target)
+        rootdir="${TARGET_DIR}"
+        sanitize_extra_args+=( "--no-standard-lib-dirs" "--relative-to-file" )

I thought we decided that target and staging should NOT be relative-to-file,
but should be absolute paths without rootdir? Or was this a problem for staging, because the linker would add the RUNPATH to the library search path and this would point to the system libs instead of target libs? According to the man page this should only be the case for a native linker, so not for a cross linker.

Grrr, that's wrong, cut an paste error :(. Fixed!

Quoted 10 lines

I don't really like having $ORIGIN-based rpaths in target, but it's no big
deal.

Regardless, the reasoning behind the choice we make should be documented here
in comments. So for host, add something to the effect that we always want $ORIGIN-based rpaths to make it relocatable. For staging, say that we want it to be the same as target. And for target, explain the choice you made.

Quoted 4 lines

support/scripts/fix-rpath line 104

Quoted 2 lines

support/scripts/fix-rpath new file +2 -0

+    while read file ; do
+    # check if it's an ELF file

Indentation is inconsistent: sometimes 4 spaces, sometimes 2 spaces (inside the

That's due to 8 spaces replaced by one tab.

Quoted 3 lines

case, and in the condition below). And here, you're switching from spaces to tabs!

I use the default indention from emacs "Shell-script[bash]" which is usually not a bad choice. I'm going to replace all tabs with spaces.

Quoted 5 lines

Quoted 2 lines

+ if ${PATCHELF} --print-rpath "${file}" > /dev/null 2>&1; then

It might be good to check if the file actually has a non-empty rpath. When
processing a second time, most rpaths are empty so they can be skipped.

I already tried that. It will make the check slower, meaning it costs more that calling patchelf a second time.

Quoted 2 lines

Maybe even add another patch to patchelf to exit early and quietly with just 0
or 1 depending on rpath presence.

Optimization of the execution time needs more careful analysis. I have a patchelf patch which just open and reads the patchelf header to check quickly if it's an ELF file. But that does not help a lot. readelf is still faster and I guess that's because it's written in C (and not C++).

Quoted 4 lines

Am 20.07.2017 um 01:02 schrieb Arnout Vandecappelle:

Quoted 3 lines · Wolfgang Grandegger

[snip]

Quoted 8 lines

Quoted 7 lines

support/scripts/fix-rpath line 40

Quoted 4 lines

support/scripts/fix-rpath new file +4 -0

+Environment:
+
+    PATCHELF    patchelf program to use
+        (default: HOST_DIR/bin/patchelf)

And also HOST_DIR, TARGET_DIR, STAGING_DIR, and
TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR.

Quoted 1 line

PATCHELF points to the patchelf utility! Or what do you mean here?

I mean, also these environment variables are used by the script. Moreover, the
_DIR variables are not optional.

[snip]

Quoted 10 lines

Quoted 9 lines

support/scripts/fix-rpath line 92

Quoted 3 lines

support/scripts/fix-rpath new file +3 -0

+    target)
+        rootdir="${TARGET_DIR}"
+        sanitize_extra_args+=( "--no-standard-lib-dirs" "--relative-to-file" )

I thought we decided that target and staging should NOT be relative-to-file,
but should be absolute paths without rootdir? Or was this a problem for staging, because the linker would add the RUNPATH to the library search path and this would point to the system libs instead of target libs? According to the man page this should only be the case for a native linker, so not for a cross linker.

Quoted 1 line

Grrr, that's wrong, cut an paste error :(. Fixed!

But staging stays the same as target, right?

And did you add comments everywhere to explain why these options are chosen?

Quoted 11 lines

Quoted 11 lines

I don't really like having $ORIGIN-based rpaths in target, but it's no big
deal.

Regardless, the reasoning behind the choice we make should be documented here
in comments. So for host, add something to the effect that we always want $ORIGIN-based rpaths to make it relocatable. For staging, say that we want it to be the same as target. And for target, explain the choice you made.

Quoted 6 lines

Quoted 4 lines

support/scripts/fix-rpath line 104

Quoted 2 lines

support/scripts/fix-rpath new file +2 -0

+    while read file ; do
+    # check if it's an ELF file

Indentation is inconsistent: sometimes 4 spaces, sometimes 2 spaces (inside the

That's due to 8 spaces replaced by one tab.

Fix your editor not to do that.

Quoted 6 lines

Quoted 3 lines

case, and in the condition below). And here, you're switching from spaces to tabs!

I use the default indention from emacs "Shell-script[bash]" which is usually not a bad choice. I'm going to replace all tabs with spaces.

Since emacs, vim and kate all have compatible mode-settings lines, feel free to
add a mode-setting line below the shebang of the script. Do test it with vim please.

Quoted 12 lines

Quoted 5 lines

Quoted 2 lines

+ if ${PATCHELF} --print-rpath "${file}" > /dev/null 2>&1; then

It might be good to check if the file actually has a non-empty rpath. When
processing a second time, most rpaths are empty so they can be skipped.

I already tried that. It will make the check slower, meaning it costs more that calling patchelf a second time.

Quoted 2 lines

Maybe even add another patch to patchelf to exit early and quietly with just 0
or 1 depending on rpath presence.

Quoted 4 lines

Optimization of the execution time needs more careful analysis. I have a patchelf patch which just open and reads the patchelf header to check quickly if it's an ELF file. But that does not help a lot. readelf is still faster and I guess that's because it's written in C (and not C++).

I have a few speedup suggestions for patchelf (but all should be in follow-up
patches, not as part of patch 1/9).

- Add a --has-rpath option that is quiet and just exits 0 or 1.
- Instead of reading into a string, mmap the file. Since in most cases the file size isn't changed, that works *very* efficiently. Note that this needs a configure.ac check (mmap is not always available, e.g. not on nommu). With mmap, it's not needed to first read the header only, since it will just pull in a page when needed. It will be slower on NFS and some FUSE filesystems though.

- Remove empty RUNPATH entries, so a second run doesn't even start.
- Link patchelf statically, preferably with -flto as well. This will probably just speed things up with a few %, but it's also on the "empty" calls so could be significant.

    case "${tree}" in
        host)
            ...
            # we always want $ORIGIN-based rpaths to make it relocatable.

            sanitize_extra_args+=( "--relative-to-file" )
            ;;

        staging)
            ...
            # should be like for the target tree below

            sanitize_extra_args+=( "--no-standard-lib-dirs" )
            ;;

        target)
            ...
            # we don't want $ORIGIN-based rpaths but absolute paths without rootdir.
            # we also want to remove rpaths pointing to /lib or /usr/lib. 

As I said, the execution time comes form scanning for ELF files. The rest doesn't matter a lot.

The attached patch speeds up ELF file checking. As said, readelf is still faster even with that patch.

Quoted 4 lines

     case "${tree}" in
         host)
             ...
             # we always want $ORIGIN-based rpaths to make it relocatable.

Perfect. Just please start the sentence with a capital (it ends with a .)

Quoted 7 lines

             sanitize_extra_args+=( "--relative-to-file" )
             ;;

         staging)
             ...
             # should be like for the target tree below

s/like/the same as/

Quoted 7 lines

             sanitize_extra_args+=( "--no-standard-lib-dirs" )
             ;;

         target)
             ...
             # we don't want $ORIGIN-based rpaths but absolute paths without rootdir.
             # we also want to remove rpaths pointing to /lib or /usr/lib.

Capitalization, otherwise perfect.

[snip]

Quoted 2 lines

As I said, the execution time comes form scanning for ELF files. The rest doesn't matter a lot.

Instead of the patch you attached, it might actually make more sense to create
a tiny C file that does this, and execute that as part of the find command. Or you could just create support/scripts/elfmagic with those 4 bytes and use "cmp -n 4 {} ${0%/*}/elfmagic".

By the way, I believe filtering with -exec is much faster than doing it with
while/if. Unfortunately you can't use that with patchelf --print-rpath because the output of patchelf would be mixed up with the find output.

Hello Arnout,

Am 20.07.2017 um 15:45 schrieb Arnout Vandecappelle:

Quoted 8 lines · Wolfgang Grandegger

Quoted 4 lines

     case "${tree}" in
         host)
             ...
             # we always want $ORIGIN-based rpaths to make it relocatable.

Quoted 1 line

Perfect. Just please start the sentence with a capital (it ends with a .)

Well, I followed the style of the original script... just to be consistent... otherwise we will have an ugly mix.

Quoted 8 lines

Quoted 3 lines

As I said, the execution time comes form scanning for ELF files. The rest doesn't
matter a lot.

Instead of the patch you attached, it might actually make more sense to create
a tiny C file that does this, and execute that as part of the find command. Or you could just create support/scripts/elfmagic with those 4 bytes and use "cmp -n 4 {} ${0%/*}/elfmagic".

Yes, I had that idea as well and I have already hacked something. The problem is that it does not check if it does have an rpath.

"cmp" is not faster, I already
tried!

Quoted 4 lines

By the way, I believe filtering with -exec is much faster than doing it with
while/if. Unfortunately you can't use that with patchelf --print-rpath because the output of patchelf would be mixed up with the find output.

I already tried various other solutions.

Just preparing v8...

Wolfgang.

Quoted 11 lines

Hello Arnout,

Am 20.07.2017 um 15:45 schrieb Arnout Vandecappelle:

Quoted 8 lines · Wolfgang Grandegger

Quoted 4 lines

      case "${tree}" in
          host)
              ...
              # we always want $ORIGIN-based rpaths to make it relocatable.

Quoted 4 lines

Quoted 1 line

Perfect. Just please start the sentence with a capital (it ends with a .)

Well, I followed the style of the original script... just to be consistent... otherwise we will have an ugly mix.

There is no original script, only an original author :-)

So indeed, fix it script-wide please.

[snip]

Quoted 11 lines

Quoted 8 lines

Quoted 3 lines

As I said, the execution time comes form scanning for ELF files. The rest doesn't
matter a lot.

Instead of the patch you attached, it might actually make more sense to create
a tiny C file that does this, and execute that as part of the find command. Or you could just create support/scripts/elfmagic with those 4 bytes and use "cmp -n 4 {} ${0%/*}/elfmagic".

Yes, I had that idea as well and I have already hacked something. The problem is that it does not check if it does have an rpath.

Well, you could do that particular check in the find -exec and keep the
--print-rpath check in the while loop.

Quoted 2 lines

"cmp" is not faster, I already
tried!

OK good. Might be a good idea to keep track of the things you already tried in
the cover letter.

Am 20.07.2017 um 16:19 schrieb Arnout Vandecappelle:

Quoted 2 lines

OK good. Might be a good idea to keep track of the things you already tried in
the cover letter.

Well, it's already a few month ago that I tried finding a good and fast solution. I tried a lot of things, be can't remember the details.

My time
working on this topic is limited! When I have more free time I will take care.

Wolfgang.

We need that pachelf utility for RPATH sanitization.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 Makefile | 6 ++++++
 1 file changed, 6 insertions(+)

Makefile +0 -0

index a22e87f..cdc3a64 100644

Makefile +1 -0

+
 .PHONY: target-post-image
 target-post-image: $(TARGETS_ROOTFS) target-finalize
 	@$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_IMAGE_SCRIPT)), \

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

Makefile +0 -0

index cdc3a64..1a826fc 100644

Makefile +0 -0

 .PHONY: target-post-image
 target-post-image: $(TARGETS_ROOTFS) target-finalize
 

Quoted 11 lines

Signed-off-by Wolfgang Grandegger <[email protected]>

---
  Makefile | 2 ++
  1 file changed, 2 insertions(+)

Makefile +0 -0

index cdc3a64..1a826fc 100644
@@ -725,6 +725,8 @@ endif
 

Makefile endif · line 729

Quoted 4 lines

Makefile +2 -0

  	@$(call MESSAGE,"Sanitizing RPATH in staging tree")
  	$(TOPDIR)/support/scripts/fix-rpath staging
+	@$(call MESSAGE,"Sanitizing RPATH in target tree")
+	$(TOPDIR)/support/scripts/fix-rpath target

I think we should do this *before* copying the overlay and calling the
post-build script. Indeed, in my mind, the user is completely responsible for what happens there, and it should never be touched by us.

Am 20.07.2017 um 01:34 schrieb Arnout Vandecappelle:

Quoted 8 lines · Wolfgang Grandegger

Quoted 5 lines

Signed-off-by Wolfgang Grandegger <[email protected]>

---
  Makefile | 2 ++
  1 file changed, 2 insertions(+)

Quoted 13 lines

Makefile endif · line 728

Quoted 9 lines

Makefile +2 -0

index cdc3a64..1a826fc 100644
@@ -725,6 +725,8 @@ endif
        @$(call MESSAGE,"Sanitizing RPATH in staging tree")
      $(TOPDIR)/support/scripts/fix-rpath staging
+    @$(call MESSAGE,"Sanitizing RPATH in target tree")
+    $(TOPDIR)/support/scripts/fix-rpath target

I think we should do this *before* copying the overlay and calling the
post-build script. Indeed, in my mind, the user is completely responsible for what happens there, and it should never be touched by us.

Well, the user will usually not care about the rpath. Therefore he might profit from the sanitization as well. Actually, the sanitization does usually not harm. The only thing I can think of is copying libraries at runtime to a dir set in an rpath. How is stripping handled?

We introduce the "finalize-host" target for that purpose.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 Makefile | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Makefile +0 -0

index 1a826fc..2a265e0 100644

Makefile +0 -0

 # When creating HOST_DIR, also symlink usr -> .
 $(HOST_DIR):
 

Quoted 12 lines

We introduce the "finalize-host" target for that purpose.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
  Makefile | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)

Makefile +0 -0

index 1a826fc..2a265e0 100644

Makefile $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) · line 561

Quoted 10 lines

Makefile +6 -1

@@ -553,7 +553,12 @@ $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
  prepare: $(BUILD_DIR)/buildroot-config/auto.conf
 
  .PHONY: world
-world: target-post-image
+world: target-post-image host-finalize
+
+.PHONY: host-finalize
+host-finalize:
+	@$(call MESSAGE,"Rendering the SDK relocatable")
+	$(TOPDIR)/support/scripts/fix-rpath host

I'm not sure why, but this is taking a very long time for me - twice as much as
target and staging together. Possibly this is because the external toolchain (which tends to be large) is also still processed. Passing TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR in the environment of this call would help.

This sanitization takes a non-trivial amount of time. For example, on a config
with basically just systemd enabled, rebuilding the rootfs tarballs without the sanitization takes just 5 seconds. target+staging sanitization adds 10 seconds to that. host sanitization adds another 20 seconds. So globally we go from 5 to 34 seconds as the baseline time to rebuild anything.

Also, we discussed this before (also with Thomas): I'm not so sure we want to
do this as part of the normal build. It would make sense to me to have a new "sdk" target which is NOT a dependency of world, that should be called explicitly to get a relocatable toolchain. That already solves a big part of the time issue I mentioned above. But it also means we can later add other things to that sdk target, like creating a tarball of it. And anyway the host sanitization is only useful if you're actually going to move the sdk somewhere else.

Also, host-finalize (or sdk) should depend on toolchain, and probably also on
$(filter host-%,$(PACKAGES)). The latter is currently incomplete, but when we get around to selecting BR2_PACKAGE_HOST_* for all host packages, we will make sure that 'make sdk' really generates the complete sdk.

And finally, I think that the staging sanitization fits better here than in
target-finalize. It has nothing to do with target, and the only reason that we do such sanitization is to make the sdk relocatable.

Am 20.07.2017 um 01:51 schrieb Arnout Vandecappelle:

Quoted 31 lines · Wolfgang Grandegger

Quoted 12 lines

We introduce the "finalize-host" target for that purpose.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
  Makefile | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)

Makefile +0 -0

index 1a826fc..2a265e0 100644

Makefile $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) · line 560

Quoted 9 lines

Makefile +6 -1

@@ -553,7 +553,12 @@ $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
  prepare: $(BUILD_DIR)/buildroot-config/auto.conf
    .PHONY: world
-world: target-post-image
+world: target-post-image host-finalize
+
+.PHONY: host-finalize
+host-finalize:
+    @$(call MESSAGE,"Rendering the SDK relocatable")
+    $(TOPDIR)/support/scripts/fix-rpath host

I'm not sure why, but this is taking a very long time for me - twice as much as
target and staging together. Possibly this is because the external toolchain (which tends to be large) is also still processed. Passing TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR in the environment of this call would help.

Quoted 5 lines

This sanitization takes a non-trivial amount of time. For example, on a config
with basically just systemd enabled, rebuilding the rootfs tarballs without the sanitization takes just 5 seconds. target+staging sanitization adds 10 seconds to that. host sanitization adds another 20 seconds. So globally we go from 5 to 34 seconds as the baseline time to rebuild anything.

Yes, that's the downside of doing it at the end of the build on all 3 trees. Most of the time is consumed for scanning for ELF files. The execution time should be therefore proportional to the number of scanned files. Maybe a database/cache could speed up things.

Could you please send me your "defconfig" to check the times here?

Quoted 7 lines

Also, we discussed this before (also with Thomas): I'm not so sure we want to
do this as part of the normal build. It would make sense to me to have a new "sdk" target which is NOT a dependency of world, that should be called explicitly to get a relocatable toolchain. That already solves a big part of the time issue I mentioned above. But it also means we can later add other things to that sdk target, like creating a tarball of it. And anyway the host sanitization is only useful if you're actually going to move the sdk somewhere else.

I already understood that "make sdk" is the preferred solution. I just thought somebody else would implement that ;).

Quoted 4 lines

Also, host-finalize (or sdk) should depend on toolchain, and probably also on
$(filter host-%,$(PACKAGES)). The latter is currently incomplete, but when we get around to selecting BR2_PACKAGE_HOST_* for all host packages, we will make sure that 'make sdk' really generates the complete sdk.

I might have missed a few things here.

Quoted 4 lines

And finally, I think that the staging sanitization fits better here than in
target-finalize. It has nothing to do with target, and the only reason that we do such sanitization is to make the sdk relocatable.

D'accord!

Wolfgang.

Quoted 40 lines

Am 20.07.2017 um 01:51 schrieb Arnout Vandecappelle:

Quoted 31 lines · Wolfgang Grandegger

Quoted 12 lines

We introduce the "finalize-host" target for that purpose.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
   Makefile | 7 ++++++-
   1 file changed, 6 insertions(+), 1 deletion(-)

Makefile +0 -0

index 1a826fc..2a265e0 100644

Makefile $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) · line 560

Quoted 9 lines

Makefile +6 -1

@@ -553,7 +553,12 @@ $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
   prepare: $(BUILD_DIR)/buildroot-config/auto.conf
     .PHONY: world
-world: target-post-image
+world: target-post-image host-finalize
+
+.PHONY: host-finalize
+host-finalize:
+    @$(call MESSAGE,"Rendering the SDK relocatable")
+    $(TOPDIR)/support/scripts/fix-rpath host

I'm not sure why, but this is taking a very long time for me - twice as much as
target and staging together. Possibly this is because the external toolchain (which tends to be large) is also still processed. Passing TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR in the environment of this call would help.

Quoted 5 lines

This sanitization takes a non-trivial amount of time. For example, on a config
with basically just systemd enabled, rebuilding the rootfs tarballs without the sanitization takes just 5 seconds. target+staging sanitization adds 10 seconds to that. host sanitization adds another 20 seconds. So globally we go from 5 to 34 seconds as the baseline time to rebuild anything.

Quoted 4 lines

Yes, that's the downside of doing it at the end of the build on all 3 trees. Most of the time is consumed for scanning for ELF files. The execution time should be therefore proportional to the number of scanned files. Maybe a database/cache could speed up things.

That was the idea behind doing things after each package build :-)

For a cache, you still need to md5 all files to detect if they have change
since the last time. Checking for an ELF header should be faster...

Quoted 1 line

Could you please send me your "defconfig" to check the times here?

It's just an external toolchain + kernel + BR2_INIT_SYSTEMD=y

Quoted 8 lines

Quoted 7 lines

Also, we discussed this before (also with Thomas): I'm not so sure we want to
do this as part of the normal build. It would make sense to me to have a new "sdk" target which is NOT a dependency of world, that should be called explicitly to get a relocatable toolchain. That already solves a big part of the time issue I mentioned above. But it also means we can later add other things to that sdk target, like creating a tarball of it. And anyway the host sanitization is only useful if you're actually going to move the sdk somewhere else.

Quoted 2 lines

I already understood that "make sdk" is the preferred solution. I just thought somebody else would implement that ;).

Well, just rename host-finalize to sdk, and remove it from the dependencies of
"world". Oh, and add it to the 'make help' output.

Documentation should be added as well, but that should be done anyway (to
explain that the relocate-sdk script should be called).

Am 20.07.2017 um 10:49 schrieb Arnout Vandecappelle:

Quoted 5 lines

Well, just rename host-finalize to sdk, and remove it from the dependencies of
"world". Oh, and add it to the 'make help' output.

Documentation should be added as well, but that should be done anyway (to
explain that the relocate-sdk script should be called).

OK, just to double-check. "make sdk" will sanitize the staging and host tree and add relocate-sdk.sh. But the target tree will always be sanitized.

Quoted 1 line

Am 20.07.2017 um 10:49 schrieb Arnout Vandecappelle:

[snip]

Quoted 3 lines

Quoted 3 lines

Well, just rename host-finalize to sdk, and remove it from the dependencies of
"world". Oh, and add it to the 'make help' output.

Quoted 5 lines

Quoted 2 lines

Documentation should be added as well, but that should be done anyway (to
explain that the relocate-sdk script should be called).

OK, just to double-check. "make sdk" will sanitize the staging and host tree and add relocate-sdk.sh. But the target tree will always be sanitized.

Exactly!

This sanitization takes a non-trivial amount of time. For example, on a config
with basically just systemd enabled, rebuilding the rootfs tarballs without the sanitization takes just 5 seconds. target+staging sanitization adds 10 seconds to that. host sanitization adds another 20 seconds. So globally we go from 5 to 34 seconds as the baseline time to rebuild anything.

Also, we discussed this before (also with Thomas): I'm not so sure we want to
do this as part of the normal build. It would make sense to me to have a new "sdk" target which is NOT a dependency of world, that should be called explicitly to get a relocatable toolchain. That already solves a big part of the time issue I mentioned above. But it also means we can later add other things to that sdk target, like creating a tarball of it. And anyway the host sanitization is only useful if you're actually going to move the sdk somewhere else.

Also, host-finalize (or sdk) should depend on toolchain, and probably also on
$(filter host-%,$(PACKAGES)). The latter is currently incomplete, but when we get around to selecting BR2_PACKAGE_HOST_* for all host packages, we will make sure that 'make sdk' really generates the complete sdk.

And finally, I think that the staging sanitization fits better here than in
target-finalize. It has nothing to do with target, and the only reason that we do such sanitization is to make the sdk relocatable.

Hello,

On Thu, 20 Jul 2017 01:51:53 +0200, Arnout Vandecappelle wrote:

Quoted 4 lines

Also, host-finalize (or sdk) should depend on toolchain, and probably also on
$(filter host-%,$(PACKAGES)). The latter is currently incomplete, but when we get around to selecting BR2_PACKAGE_HOST_* for all host packages, we will make sure that 'make sdk' really generates the complete sdk.

For the SDK, you also need to build all the target packages. The SDK contains the sysroot (i.e STAGING_DIR), where the target packages install libraries and headers.

Basically, sdk needs to depend on "world".

Quoted 3 lines

And finally, I think that the staging sanitization fits better here than in
target-finalize. It has nothing to do with target, and the only reason that we do such sanitization is to make the sdk relocatable.

The sanitization in staging and target has nothing to do with making the SDK relocatable. Why do you think it's related ?

Best regards,

Thomas

Quoted 8 lines

Quoted 4 lines

Also, host-finalize (or sdk) should depend on toolchain, and probably also on
$(filter host-%,$(PACKAGES)). The latter is currently incomplete, but when we get around to selecting BR2_PACKAGE_HOST_* for all host packages, we will make sure that 'make sdk' really generates the complete sdk.

For the SDK, you also need to build all the target packages. The SDK contains the sysroot (i.e STAGING_DIR), where the target packages install libraries and headers.

This is what I wrote in an earlier reply to Wolfgang.

Quoted 1 line

Basically, sdk needs to depend on "world".

Not really, it doesn't need to depend on target-finalize or the rootfs targets.

Quoted 6 lines

Quoted 3 lines

And finally, I think that the staging sanitization fits better here than in
target-finalize. It has nothing to do with target, and the only reason that we do such sanitization is to make the sdk relocatable.

The sanitization in staging and target has nothing to do with making the SDK relocatable. Why do you think it's related ?

target indeed has nothing to do with making the SDK relocatable. It is only
needed to deal with stupid packages that don't correctly use --prefix/DESTDIR and that end up putting the full absolute build-time directory in rpath.

staging is different. Sanitizing staging is not really needed, in the sense
that any rpath in there is simply not going to be used. We want to sanitize staging for the following reasons:

- To avoid leaking references to the original output directory. This way, we can validate that the SDK is relocatable by running a simple "grep -r ${BASE_DIR} ${HOST_DIR}". Obviously RPATH sanitization is not sufficient (e.g. also the references to source files have to be stripped), but it's a step in the right direction. This reason is obviously only relevant for the SDK.

- To make sure that when an executable is copied to target that it actually executes correctly. Since within Buildroot we never copy stuff from staging to target, this is clearly only relevant for the SDK.

Hello,

On Thu, 20 Jul 2017 15:58:49 +0200, Arnout Vandecappelle wrote:

Quoted 3 lines

Quoted 1 line

Basically, sdk needs to depend on "world".

Not really, it doesn't need to depend on target-finalize or the rootfs targets.

Correct, but I am not sure it is really worth being smart here.

So do we agree that:

- target sanitization will be done in target-finalize

- staging sanitization will be done in "make sdk"

- host sanitization will be done in "make sdk"

Correct ?

The script "relocate-sdk.sh" is installed into the top directory of the SDK (HOST_DIR) and the SDK location path is stored in the file "HOST_DIR/share/buildroot/sdk-location"-

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

Makefile +2 -0

index 2a265e0..32f85e8 100644
@@ -559,6 +559,8 @@ world: target-post-image host-finalize
 host-finalize:
 	@$(call MESSAGE,"Rendering the SDK relocatable")
 	$(TOPDIR)/support/scripts/fix-rpath host
+	install $(TOPDIR)/support/misc/relocate-sdk.sh $(HOST_DIR)
+	echo $(HOST_DIR) > $(HOST_DIR)/share/buildroot/sdk-location
 
 # When creating HOST_DIR, also symlink usr -> .
 $(HOST_DIR):

The location of the buildroot SDK is stored in the file "sdk-location" in "share/buildroot". If it's content does not match the current SDK location, ask the user to run the script "relocate-sdk.sh" in the top directory once. The external toolchain may be a pre-installed one in a directory that is not writeable by us. Therefore, we can't run the script directly.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 toolchain/helpers.mk                                   | 18 ++++++++++++++++++
 toolchain/toolchain-external/pkg-toolchain-external.mk |  1 +
 2 files changed, 19 insertions(+)

toolchain/helpers.mk +0 -0

index 6136aef..5c6539e 100644
@@ -476,3 +476,21 @@ define simplify_symlink
 	ln -sf "$${DOTS}$${REL_DEST}" "$${FULL_SRC}" ; \
 )

toolchain/helpers.mk +7 -0

+		if [ "`cat $(1)/share/buildroot/sdk-location`" != "$${sdkroot}" ]; then \
+			echo "Please relocate the buildroot SDK by executing \"$${sdkroot}/relocate-sdk.sh\" once!" ; \
+			exit 1 ; \
+		fi \
+	fi \
+)
+endef

toolchain/toolchain-external/pkg-toolchain-external.mk +1 -0

index 33449d3..afccbb6 100644
@@ -519,6 +519,7 @@ endif
 # matches the configuration provided in Buildroot: ABI, C++ support,
 # kernel headers version, type of C library and all C library features.
 define $(2)_CONFIGURE_CMDS
+	$$(Q)$$(call check_buildroot_sdk_relocated,$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR))
 	$$(Q)$$(call check_cross_compiler_exists,$$(TOOLCHAIN_EXTERNAL_CC))
 	$$(Q)$$(call check_unusable_toolchain,$$(TOOLCHAIN_EXTERNAL_CC))
 	$$(Q)SYSROOT_DIR="$$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC))" ; \

This is because $(HOST_DIR)/usr is gone.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 support/misc/relocate-sdk.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

support/misc/relocate-sdk.sh +1 -1

index 2a9ebc9..729353a 100755
@@ -5,7 +5,7 @@ if [ "$#" -ne 0 ]; then
     exit 1
 fi
 
-LOCFILE="usr/share/buildroot/sdk-location"
+LOCFILE="share/buildroot/sdk-location"
 FILEPATH="$(readlink -f "$0")"
 NEWPATH="$(dirname "${FILEPATH}")"
 

This is because $(HOST_DIR)/usr is gone.

Signed-off-by Wolfgang Grandegger <[email protected]>

---
 support/misc/relocate-sdk.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Samuel Martin (1):
support/scripts: add fix-rpath script to sanitize the rpath

Wolfgang Grandegger (8):
package/patchelf: add patch for rpath sanitization under a root
directory
core: sanitize RPATH in staging tree at the end of target finalization
core: sanitize RPATH in target tree at the end of target finalization
core: sanitize RPATH in host tree at the very end of the build
core: install relocation script and location at the end of the build
external-toolchain: check if a buildroot SDK has already been
relocated
support/scripts: relocate-sdk.sh now creates sdk-location in
share/buildroot
package/qt5base: provide "qt.conf" to make "qmake" relocatable