| Message ID | 51297962-b3bc-bd68-8dee-3a1ad8ca92ae@grandegger.com |
|---|---|
| State | Not Applicable |
| Headers | show |
Hello, On Wed, 5 Jul 2017 15:48:22 +0200, Wolfgang Grandegger wrote: > What about making the relocation stuff configurable as shown in the patch below. > The advantage is that it could also control the generation of the "qt.conf", > for example. We don't want to make it configurable, through a Config.in option. However, we would like to have a separate make target that prepares the SDK, creates the tarball, etc. Basically, a normal "make" would not run all the rpath sanitization logic, absolute path replacement, etc. There should be a separate "make sdk" target that does this. Best regards, Thomas
Am 05.07.2017 um 16:13 schrieb Thomas Petazzoni: > Hello, > > On Wed, 5 Jul 2017 15:48:22 +0200, Wolfgang Grandegger wrote: > >> What about making the relocation stuff configurable as shown in the patch below. >> The advantage is that it could also control the generation of the "qt.conf", >> for example. > > We don't want to make it configurable, through a Config.in option. > However, we would like to have a separate make target that prepares the > SDK, creates the tarball, etc. > > Basically, a normal "make" would not run all the rpath sanitization > logic, absolute path replacement, etc. There should be a separate "make > sdk" target that does this. Yes I understand, but how do you want to handle static things like the creation of "qt.conf" required for the relocatable SDK? Wolfgang.
On 05-07-17 15:48, Wolfgang Grandegger wrote: > Hello, > > Am 05.07.2017 um 12:28 schrieb Wolfgang Grandegger: >> Am 05.07.2017 um 11:30 schrieb Wolfgang Grandegger: >>> Hello Arnout, >>> >>> Am 05.07.2017 um 10:59 schrieb Arnout Vandecappelle: >>>> Hi Wolfgang, >>>> >>>> On 04-07-17 18:22, Wolfgang Grandegger wrote: >>>>> The file "qt.conf" can be used to override the hard-coded paths that are >>>>> compiled into the Qt library. We need it to make "qmake" relocatable. >>>> >>>> All qt5 packages are failing because of this, e.g. >>>> http://autobuild.buildroot.net/results/33e/33eb7b7ef7d232bed2432d1d44fd80a4fc8c4e2d >>>> >>>> >>>> qt5serialport: installs files in >>>> /accts/mlweber1/instance-2/output/host/usr/x86_64-buildroot-linux-uclibc/sysroot//accts/mlweber1/instance-2/output >>>> >>>> >>>> >>>> Can you have a look? >>> >>> I know the problem! The patched used an old version (from an old series) >>> of "qt.conf.in"..., sorry! >> >> The patch is reverted now. So just for the records, the patch below >> fixes the problem. I'm going to provide a proper patch with my next >> series. This also shows, that if "qt.conf" is in place, it's active and >> will always overwrite the pathes compiled into qmake... which will break >> the idea of "make sdk" somehow. > > What about making the relocation stuff configurable as shown in the patch below. > The advantage is that it could also control the generation of the "qt.conf", > for example. I don't really think this is worth it. Much simpler to always have the possibility to sdk-ize it by running 'make sdk'. > > Wolfgang. > >>From 43ef9954f1b5b92e97b5774081a263f2ce068c5f Mon Sep 17 00:00:00 2001 > From: Wolfgang Grandegger <wg@grandegger.com> > Date: Wed, 5 Jul 2017 15:36:21 +0200 > Subject: [RFC PATCH] core: add config option to make SDK (host dir) relocatable > > --- > Config.in | 18 ++++++++++++++++++ > Makefile | 5 +++++ > 2 files changed, 23 insertions(+) > > diff --git a/Config.in b/Config.in > index 72ceadf..57f899c 100644 > --- a/Config.in > +++ b/Config.in > @@ -721,6 +721,24 @@ config BR2_REPRODUCIBLE > This is labeled as an experimental feature, as not all > packages behave properly to ensure reproducibility. > > +config BR2_RELOCATABLE > + bool "Make a relocatable SDK (experimental)" > + help > + This option will build a relocatable SDK (host dir). That > + is the directory to store all the binary files that are > + built for the host but also the cross compilation toolchain > + when building the internal buildroot toolchain. It also > + includes the "sysroot" tree required for cross compilation. > + The relocatable host directory can then be moved to a new > + location as shown below: > + > + $ cd <buildroot-build-directory> > + $ cp -r host <the-new-directory>/sdk > + $ <the-new-directory>/sdk/relocate-sdk.sh > + > + After executing the script "relocate-sdk.sh" once, it can > + be used for external builds. This text is very useful but should be in the manual instead. > + > endmenu > > endmenu > diff --git a/Makefile b/Makefile > index 57191d1..962f80a 100644 > --- a/Makefile > +++ b/Makefile > @@ -460,6 +460,7 @@ endif > # these locations, so export them so it is easier to use > export BR2_CONFIG > export BR2_REPRODUCIBLE > +export BR2_RELOCATABLE > export TARGET_DIR > export STAGING_DIR > export HOST_DIR > @@ -554,10 +555,12 @@ world: target-post-image host-finalize > > .PHONY: host-finalize > host-finalize: Make this 'sdk' instead of host-finalize, and add it to help: as well. > +ifeq ($(BR2_RELOCATABLE),y) > @$(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 > +endif > > # We need patchelf for RPATH sanitization > PACKAGES += host-patchelf > @@ -730,10 +733,12 @@ endif > $(call MESSAGE,"Executing post-build script $(s)"); \ > $(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep)) > > +ifeq ($(BR2_RELOCATABLE),y) > @$(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 This has nothing to do with making it relocatable, it is always necessary to sanitize the rpaths in target. Well, it's not really necessary, things work as they are now, but it would be an improvement. Regards, Arnout > +endif > > .PHONY: target-post-image > target-post-image: $(TARGETS_ROOTFS) target-finalize >
Hello, On Wed, 5 Jul 2017 16:33:35 +0200, Wolfgang Grandegger wrote: > > We don't want to make it configurable, through a Config.in option. > > However, we would like to have a separate make target that prepares the > > SDK, creates the tarball, etc. > > > > Basically, a normal "make" would not run all the rpath sanitization > > logic, absolute path replacement, etc. There should be a separate "make > > sdk" target that does this. > > Yes I understand, but how do you want to handle static things like the > creation of "qt.conf" required for the relocatable SDK? In order to make sure that the SDK situation is as close to a normal Buildroot usage, I think the qt.conf file should always be created and used by qmake. So basically, the Qt package in Buildroot should create and install this file. Am I missing something here? Thomas
On 05-07-17 16:33, Wolfgang Grandegger wrote: > > > Am 05.07.2017 um 16:13 schrieb Thomas Petazzoni: >> Hello, >> >> On Wed, 5 Jul 2017 15:48:22 +0200, Wolfgang Grandegger wrote: >> >>> What about making the relocation stuff configurable as shown in the patch below. >>> The advantage is that it could also control the generation of the "qt.conf", >>> for example. >> >> We don't want to make it configurable, through a Config.in option. >> However, we would like to have a separate make target that prepares the >> SDK, creates the tarball, etc. >> >> Basically, a normal "make" would not run all the rpath sanitization >> logic, absolute path replacement, etc. There should be a separate "make >> sdk" target that does this. > > Yes I understand, but how do you want to handle static things like the creation > of "qt.conf" required for the relocatable SDK? It should still work if you have the relocatable SDK option selected. So basically we want the option to always be selected and things to still work. Regards, Arnout
Hello, Am 05.07.2017 um 16:48 schrieb Thomas Petazzoni: > Hello, > > On Wed, 5 Jul 2017 16:33:35 +0200, Wolfgang Grandegger wrote: > >>> We don't want to make it configurable, through a Config.in option. >>> However, we would like to have a separate make target that prepares the >>> SDK, creates the tarball, etc. >>> >>> Basically, a normal "make" would not run all the rpath sanitization >>> logic, absolute path replacement, etc. There should be a separate "make >>> sdk" target that does this. >> >> Yes I understand, but how do you want to handle static things like the >> creation of "qt.conf" required for the relocatable SDK? > > In order to make sure that the SDK situation is as close to a normal > Buildroot usage, I think the qt.conf file should always be created and > used by qmake. So basically, the Qt package in Buildroot should create > and install this file. > > Am I missing something here? It works here (with my usecase)! But the qmake internals are not really transparent (not documented) and may break if new path variables are added etc.(by Qt). But well, then we just need to fix it. Let see how good qt.conf works... Wolfgang.
diff --git a/Config.in b/Config.in index 72ceadf..57f899c 100644 --- a/Config.in +++ b/Config.in @@ -721,6 +721,24 @@ config BR2_REPRODUCIBLE This is labeled as an experimental feature, as not all packages behave properly to ensure reproducibility. +config BR2_RELOCATABLE + bool "Make a relocatable SDK (experimental)" + help + This option will build a relocatable SDK (host dir). That + is the directory to store all the binary files that are + built for the host but also the cross compilation toolchain + when building the internal buildroot toolchain. It also + includes the "sysroot" tree required for cross compilation. + The relocatable host directory can then be moved to a new + location as shown below: + + $ cd <buildroot-build-directory> + $ cp -r host <the-new-directory>/sdk + $ <the-new-directory>/sdk/relocate-sdk.sh + + After executing the script "relocate-sdk.sh" once, it can + be used for external builds. + endmenu endmenu diff --git a/Makefile b/Makefile index 57191d1..962f80a 100644 --- a/Makefile +++ b/Makefile @@ -460,6 +460,7 @@ endif # these locations, so export them so it is easier to use export BR2_CONFIG export BR2_REPRODUCIBLE +export BR2_RELOCATABLE export TARGET_DIR export STAGING_DIR export HOST_DIR @@ -554,10 +555,12 @@ world: target-post-image host-finalize .PHONY: host-finalize host-finalize: +ifeq ($(BR2_RELOCATABLE),y) @$(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 +endif # We need patchelf for RPATH sanitization PACKAGES += host-patchelf @@ -730,10 +733,12 @@ endif $(call MESSAGE,"Executing post-build script $(s)"); \ $(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep)) +ifeq ($(BR2_RELOCATABLE),y) @$(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 +endif .PHONY: target-post-image target-post-image: $(TARGETS_ROOTFS) target-finalize