Make the SDK relocatable

The normal shell does not support the bashism "< <(...)". Therefore we use a normal pipe to find files containing a specific string.

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

---
 support/misc/relocate-sdk.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

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

---
 ...move-apparently-incorrect-usage-of-static.patch |  56 ++++
 ...unction-for-splitting-a-colon-separated-s.patch |  63 ++++
 ...to-make-the-rpath-relative-under-a-specif.patch | 332 +++++++++++++++++++++
 3 files changed, 451 insertions(+)
 create mode 100644 package/patchelf/0001-Remove-apparently-incorrect-usage-of-static.patch
 create mode 100644 package/patchelf/0002-Extract-a-function-for-splitting-a-colon-separated-s.patch
 create mode 100644 package/patchelf/0003-Add-option-to-make-the-rpath-relative-under-a-specif.patch

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

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

---
 support/scripts/fix-rpath | 133 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100755 support/scripts/fix-rpath

Quoted 1 line

Quoted 1 line

Sanitizing RPATH in target tree

Hello,

Quoted 7 lines · Wolfgang Grandegger

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>".

Quoted 7 lines

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

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

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

---
 support/scripts/fix-rpath | 133 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100755 support/scripts/fix-rpath

I've applied to master, after removing trailing slashes.

However, I noticed that when patchelf is not available in HOST_DIR, this script does nothing, but doesn't show any error:

thomas at windsurf:~/projets/buildroot (master)$ rm output/host/usr/bin/patchelf thomas at windsurf:~/projets/buildroot (master)$ make
[...]

Quoted 1 line

Quoted 1 line

Quoted 1 line

Sanitizing RPATH in target tree

/home/thomas/projets/buildroot/support/scripts/fix-rpath target thomas at windsurf:~/projets/buildroot (master)$

This is a little bit disturbing, so I believe it should be fixed in a follow-up patch.

Quoted 5 lines

Quoted 3 lines

 support/scripts/fix-rpath | 133 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100755 support/scripts/fix-rpath  

I've applied to master, after removing trailing slashes.

Which trailing slashes?

Quoted 2 lines

This is a little bit disturbing, so I believe it should be fixed in a follow-up patch.

Right! That's because the "if ${PATCHELF} ..." just fails and the error is
redirected to /dev/null.

Better check if ${PATCHELF} is executable somewhere in the beginning.

However, there is never a guarantee. If e.g. it would be missing a shared
library, it would still fail in the same way. To be really sure, you'd have do e.g. call patchelf on itself to verify it is actually working.

Quoted 18 lines

Hello,

Quoted 7 lines · Wolfgang Grandegger

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>".

Quoted 7 lines

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

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

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

---
  support/scripts/fix-rpath | 133 ++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 133 insertions(+)

create mode 100755 support/scripts/fix-rpath

Quoted 1 line

I've applied to master, after removing trailing slashes.

Which trailing slashes?

Quoted 6 lines

However, I noticed that when patchelf is not available in HOST_DIR, this script does nothing, but doesn't show any error:

thomas at windsurf:~/projets/buildroot (master)$ rm output/host/usr/bin/patchelf thomas at windsurf:~/projets/buildroot (master)$ make
[...]

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Sanitizing RPATH in target tree

/home/thomas/projets/buildroot/support/scripts/fix-rpath target thomas at windsurf:~/projets/buildroot (master)$

This is a little bit disturbing, so I believe it should be fixed in a follow-up patch.

Right! That's because the "if ${PATCHELF} ..." just fails and the error is
redirected to /dev/null.

  Better check if ${PATCHELF} is executable somewhere in the beginning.

However, there is never a guarantee. If e.g. it would be missing a shared
library, it would still fail in the same way. To be really sure, you'd have do e.g. call patchelf on itself to verify it is actually working.

Quoted 10 lines

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Sanitizing RPATH in target tree

/home/thomas/projets/buildroot/support/scripts/fix-rpath target thomas at windsurf:~/projets/buildroot (master)$

This is a little bit disturbing, so I believe it should be fixed in a follow-up patch.

Right! That's because the "if ${PATCHELF} ..." just fails and the error is
redirected to /dev/null.

Quoted 5 lines

  Better check if ${PATCHELF} is executable somewhere in the beginning.

However, there is never a guarantee. If e.g. it would be missing a shared
library, it would still fail in the same way. To be really sure, you'd have do e.g. call patchelf on itself to verify it is actually working.

Or you can set "PATCHELF_DEBUG=1" to check what patchelf is doing.

Hello,

Quoted 10 lines · Wolfgang Grandegger

Quoted 10 lines

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Sanitizing RPATH in target tree

/home/thomas/projets/buildroot/support/scripts/fix-rpath target thomas at windsurf:~/projets/buildroot (master)$

This is a little bit disturbing, so I believe it should be fixed in a follow-up patch.

Right! That's because the "if ${PATCHELF} ..." just fails and the error is
redirected to /dev/null.

Quoted 7 lines

Quoted 5 lines

   Better check if ${PATCHELF} is executable somewhere in the beginning.

However, there is never a guarantee. If e.g. it would be missing a shared
library, it would still fail in the same way. To be really sure, you'd have do e.g. call patchelf on itself to verify it is actually working.

Or you can set "PATCHELF_DEBUG=1" to check what patchelf is doing.

We're not interested in knowing what patchelf is doing. My initial report is that if the patchelf binary doesn't exist, the script runs without reporting any error:

- Nothing on stdout/stderr
- The script has an exit code of 0

This is not good: the script should at the very least return a non-zero error code if patchelf isn't available, and should probably display an error as well.

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

On 20-07-17 16:35, Wolfgang Grandegger wrote:
[snip]

You forgot:

Quoted 1 line

+ 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

[snip]

support/scripts/fix-rpath line 76

Quoted 2 lines

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

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

Unneeded ;

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

---
 package/patchelf/Config.in.host | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

package/patchelf/Config.in.host +0 -0

index d1c8375..7b19e6a 100644

We sanitize the RPATH of ELF files in the target tree to deal with stupid packages that don't correctly use --prefix/DESTDIR and that end up putting the full absolute build-time directory in the RPATH.

We do it before copying the overlay and calling the post-build script. The user is completely responsible for what happens in the last two steps, and it should never be touched by us.

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

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

We use a separate make target to build a relocatable SDK. We first sanitize the RPATH in host tree depending on the toolchain.

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

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

Makefile +0 -0

index d4faa02..3019081 100644

Makefile +4 -0

+	@$(call MESSAGE,"Rendering the SDK relocatable")
+	$(TOPDIR)/support/scripts/fix-rpath host
+
 # Compatibility symlink in case a post-build script still uses $(HOST_DIR)/usr
 $(HOST_DIR)/usr: $(HOST_DIR)
 	@ln -snf . $@

@@ -1001,6 +1006,7 @@ help:
 	@echo 'Build:'
 	@echo '  all                    - make world'
 	@echo '  toolchain              - build toolchain'
+	@echo '  sdk                    - build relocatable SDK'
 	@echo
 	@echo 'Configuration:'
 	@echo '  menuconfig             - interactive curses-based configurator'

As mentioned by Thomas, this should depend on "world", not just toolchain.
Indeed, plenty of host packages are built *after* the toolchain. You could add ${PACKAGES} as a dependency, but that still misses the dependencies of the rootfs targets that don't have a Kconfig option. So depending on "world" is the easiest.

With that (and updating the commit message accordingly):

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

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                                   | 16 ++++++++++++++++
 toolchain/toolchain-external/pkg-toolchain-external.mk |  1 +
 2 files changed, 17 insertions(+)

Hello,

Quoted 7 lines · Wolfgang Grandegger

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.

Quoted 5 lines

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

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

Now that I think of it, this is going to be a bit annoying. This means that whenever you want to use a Buildroot-generated toolchain as an external toolchain in another Buildroot configuration, you have to run this relocate script.

This will break a lot of things, like the autobuilders, the runtime test infrastructure, etc. that all rely on pre-built Buildroot toolchains, but don't run the relocate-sdk script. In addition, we simply can't do it, because it's directly Buildroot itself that downloads the toolchain tarball and extracts it, so we don't even get the opportunity to run the relocate-sdk script.

Therefore, I cannot apply this as-is, a better solution needs to be found.

Best regards,

Thomas

Quoted 11 lines

Now that I think of it, this is going to be a bit annoying. This means that whenever you want to use a Buildroot-generated toolchain as an external toolchain in another Buildroot configuration, you have to run this relocate script.

This will break a lot of things, like the autobuilders, the runtime test infrastructure, etc. that all rely on pre-built Buildroot toolchains, but don't run the relocate-sdk script. In addition, we simply can't do it, because it's directly Buildroot itself that downloads the toolchain tarball and extracts it, so we don't even get the opportunity to run the relocate-sdk script.

Well, we could run the script directly for downloaded toolchains, and do the
check for pre-installed toolchains. Does that sound acceptable?

I'm probably forgetting something though :-)

Hello,

Quoted 12 lines · Arnout Vandecappelle

Quoted 11 lines

Now that I think of it, this is going to be a bit annoying. This means that whenever you want to use a Buildroot-generated toolchain as an external toolchain in another Buildroot configuration, you have to run this relocate script.

This will break a lot of things, like the autobuilders, the runtime test infrastructure, etc. that all rely on pre-built Buildroot toolchains, but don't run the relocate-sdk script. In addition, we simply can't do it, because it's directly Buildroot itself that downloads the toolchain tarball and extracts it, so we don't even get the opportunity to run the relocate-sdk script.

Quoted 4 lines

Well, we could run the script directly for downloaded toolchains, and do the
check for pre-installed toolchains. Does that sound acceptable?

I'm probably forgetting something though :-)

In fact, I wonder why this check is necessary at all, for the use case of an external toolchain. Indeed, an external toolchain is really a very minimal SDK, with just gcc/binutils/gdb/libc. And there is nothing that relocate-sdk will relocate in such a simple SDK: SDKs that are just toolchains are relocatable by design, with no fixup needed.

The relocate-sdk is useful when you start having more stuff in the SDK, with libtool files and other weird things that hardcore paths. But that's not the case for the SDK-is-just-a-toolchain case.

Therefore, I would suggest to simply drop this check.

Quoted 1 line

Therefore, I would suggest to simply drop this check.

If you make a toolchain with "make toolchain" the check will not harm. If it's created with "make sdk" it will do the check because "share/buildroot/sdk-location" does exist. "make sdk" will never create just the toolchain.

Hello,

Quoted 6 lines · Wolfgang Grandegger

Quoted 1 line

Therefore, I would suggest to simply drop this check.

If you make a toolchain with "make toolchain" the check will not harm. If it's created with "make sdk" it will do the check because "share/buildroot/sdk-location" does exist. "make sdk" will never create just the toolchain.

"make sdk" will definitely create just the toolchain if what you have in your configuration is... just the toolchain, which is exactly how I build Buildroot toolchains, such as the ones used by the autobuilders or on toolchains.free-electrons.com.

Doing "make toolchain" doesn't work for this use case, because you definitely want the RPATH sanitization of host binaries done in "make sdk".

Again, I think this additional check in the external toolchain code is useless. For a SDK to be usable as an external toolchain, it has to be a SDK that contains *just* a toolchain and *nothing* else. If its sysroot is polluted with additional libraries than the C library, it cannot be used as an external toolchain. And therefore, the relocate-sdk procedure is useless, because there's nothing to relocate in an SDK that is just a toolchain.

Quoted 9 lines

"make sdk" will definitely create just the toolchain if what you have in your configuration is... just the toolchain, which is exactly how I build Buildroot toolchains, such as the ones used by the autobuilders or on toolchains.free-electrons.com.

Doing "make toolchain" doesn't work for this use case, because you definitely want the RPATH sanitization of host binaries done in "make sdk".

Quoted 7 lines

Again, I think this additional check in the external toolchain code is useless. For a SDK to be usable as an external toolchain, it has to be a SDK that contains *just* a toolchain and *nothing* else. If its sysroot is polluted with additional libraries than the C library, it cannot be used as an external toolchain. And therefore, the relocate-sdk procedure is useless, because there's nothing to relocate in an SDK that is just a toolchain.

OK. I see. Then I will drop this patch.

Quoted 4 lines

Quoted 4 lines

For a SDK to be usable as an external toolchain, it has to be a SDK that contains *just* a toolchain and *nothing* else. If its sysroot is polluted with additional libraries than the C library, it cannot be used as an external toolchain.

Quoted 5 lines

Quoted 3 lines

And therefore, the
relocate-sdk procedure is useless, because there's nothing to relocate in an SDK that is just a toolchain.

OK. I see. Then I will drop this patch.

Let's see if Arnout agrees with my reasoning. Quite often he points me at details I have missed :-)

This is not true. I already regularly use a Buildroot SDK in projects by
setting BR2_HOST_DIR=/opt/... and packaging that. This SDK is then used to create a rootfs+kernel with Buildroot, and separately to build applications. Since the applications need some additional libraries, these libraries are included in the SDK. They are not used by Buildroot, so it's double work (they are included in the SDK, and built again for the target rootfs).

Admittedly it's not perfect, but it works. At least, as long as you don't go
and update Buildroot (thus putting new versions of the libraries on the target) without updating the SDK as well.

However...

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

And therefore, the
relocate-sdk procedure is useless, because there's nothing to relocate in an SDK that is just a toolchain.

OK. I see. Then I will drop this patch.

Quoted 2 lines

Let's see if Arnout agrees with my reasoning. Quite often he points me at details I have missed :-)

relocate-sdk is still useless when using it as an external toolchain. You could
say it makes sense for a pre-installed toolchain, but then only if you're using that SDK outside of Buildroot. Buildroot is not going to use any of the additional stuff.

Hello,

Quoted 6 lines · Arnout Vandecappelle

This is not true. I already regularly use a Buildroot SDK in projects by
setting BR2_HOST_DIR=/opt/... and packaging that. This SDK is then used to create a rootfs+kernel with Buildroot, and separately to build applications. Since the applications need some additional libraries, these libraries are included in the SDK. They are not used by Buildroot, so it's double work (they are included in the SDK, and built again for the target rootfs).

This is really horrible, because it means that some libraries that Buildroot doesn't know about may be present in the toolchain sysroot, be detected by packages, etc.

Quoted 4 lines

relocate-sdk is still useless when using it as an external toolchain. You could
say it makes sense for a pre-installed toolchain, but then only if you're using that SDK outside of Buildroot. Buildroot is not going to use any of the additional stuff.

Sorry, but I did not understand this paragraph :/

The file "qt.conf" can be used to override the hard-coded paths that are compiled into the Qt library. This is required to make "qmake" relocatable. Actually, we need to specify all variables to overwrite the compiled in values.

CC Julien Corjon <[email protected]>

CC Peter Seiderer <[email protected]>

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

---
 package/qt5/qt5base/qt.conf.in | 19 +++++++++++++++++++
 package/qt5/qt5base/qt5base.mk |  8 ++++++++
 2 files changed, 27 insertions(+)
 create mode 100644 package/qt5/qt5base/qt.conf.in