Message ID | 1507120908-48104-1-git-send-email-matthew.weber@rockwellcollins.com |
---|---|
State | Changes Requested |
Headers | show |
Series | [v3] HOST_DIR/lib: symlink respectively to lib32/64 | expand |
On středa 4. října 2017 14:41:48 CEST, Matt Weber wrote: > Discovered the issue on a RHEL7.4 machine where > the cmake build dynamically selected HOST_DIR/lib64 > as the installation path for the lzo2 library. > > Fixes failures like the following: > host-mtd > http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/ > > host-squashfs > http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/ > > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> > --- > Changes > [Yann > v2 -> v3 > - Updated hostarch logic to check for 64bit in the name > and if present create link. This supports all archs > vs just x86. > > v1 -> v2 > - Correct the condition used to determine host arch. > (Previously used the target arch check) > --- > Makefile | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 9b09589..601de1d 100644 > --- a/Makefile > +++ b/Makefile > @@ -542,7 +542,7 @@ endif > > .PHONY: dirs > dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \ > - $(HOST_DIR) $(HOST_DIR)/usr $(BINARIES_DIR) > + $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR) > > $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) > $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" > HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig > @@ -565,6 +565,13 @@ sdk: world > $(HOST_DIR)/usr: $(HOST_DIR) > @ln -snf . $@ > > +$(HOST_DIR)/lib: $(HOST_DIR) > + @mkdir -p $@ > + case $(HOSTARCH) in \ > + (*64) ln -s lib $(@D)/lib64;; \ > + (*) ln -s lib $(@D)/lib32;; \ > + esac > + > # Populating the staging with the base directories is handled > by the skeleton package > $(STAGING_DIR): > @mkdir -p $(STAGING_DIR) Thanks, I was hitting a same issue with another package that I was working on yesterday. I think that anybody whose distribution sets up CMake to use lib64 for libdir will hit that, at least on package which include GNUInstallDirs.cmake. I can confirm that this patch fixes that issue for me. Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> (host: x86_64, targets: i686, arm) Cheers, Jan
Hi Matt, On 04-10-17 14:41, Matt Weber wrote: > Discovered the issue on a RHEL7.4 machine where > the cmake build dynamically selected HOST_DIR/lib64 > as the installation path for the lzo2 library. > > Fixes failures like the following: > host-mtd > http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/ > > host-squashfs > http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/ > > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> Two small nits... > --- > Changes > [Yann > v2 -> v3 > - Updated hostarch logic to check for 64bit in the name > and if present create link. This supports all archs > vs just x86. > > v1 -> v2 > - Correct the condition used to determine host arch. > (Previously used the target arch check) > --- > Makefile | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 9b09589..601de1d 100644 > --- a/Makefile > +++ b/Makefile > @@ -542,7 +542,7 @@ endif > > .PHONY: dirs > dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \ > - $(HOST_DIR) $(HOST_DIR)/usr $(BINARIES_DIR) > + $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR) > > $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) > $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig > @@ -565,6 +565,13 @@ sdk: world > $(HOST_DIR)/usr: $(HOST_DIR) > @ln -snf . $@ > > +$(HOST_DIR)/lib: $(HOST_DIR) > + @mkdir -p $@ > + case $(HOSTARCH) in \ Better put @ in front here. > + (*64) ln -s lib $(@D)/lib64;; \ Probably not really important, but what would HOSTARCH be on a MIP64 n32? More importantly: it is possible that HOST_DIR/lib64 exists already but that HOST_DIR ends up newer - for example because a new directory (e.g. sbin) was created in it. Then the rule will be executed again, and a new symlink will be created within the lib directory. So to avoid this, use ln -snf. To be sure, could you test with BR2_HOST_DIR set to somewhere else and also rebuilding? Regards, Arnout > + (*) ln -s lib $(@D)/lib32;; \ > + esac > + > # Populating the staging with the base directories is handled by the skeleton package > $(STAGING_DIR): > @mkdir -p $(STAGING_DIR) >
Arnout, On Wed, Oct 4, 2017 at 3:37 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > Hi Matt, > > On 04-10-17 14:41, Matt Weber wrote: >> Discovered the issue on a RHEL7.4 machine where >> the cmake build dynamically selected HOST_DIR/lib64 >> as the installation path for the lzo2 library. >> >> Fixes failures like the following: >> host-mtd >> http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/ >> >> host-squashfs >> http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/ >> >> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> > > Two small nits... > >> --- >> Changes >> [Yann >> v2 -> v3 >> - Updated hostarch logic to check for 64bit in the name >> and if present create link. This supports all archs >> vs just x86. >> >> v1 -> v2 >> - Correct the condition used to determine host arch. >> (Previously used the target arch check) >> --- >> Makefile | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/Makefile b/Makefile >> index 9b09589..601de1d 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -542,7 +542,7 @@ endif >> >> .PHONY: dirs >> dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \ >> - $(HOST_DIR) $(HOST_DIR)/usr $(BINARIES_DIR) >> + $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR) >> >> $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) >> $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig >> @@ -565,6 +565,13 @@ sdk: world >> $(HOST_DIR)/usr: $(HOST_DIR) >> @ln -snf . $@ >> >> +$(HOST_DIR)/lib: $(HOST_DIR) >> + @mkdir -p $@ >> + case $(HOSTARCH) in \ > > Better put @ in front here. > >> + (*64) ln -s lib $(@D)/lib64;; \ So like the following but not the ln lines? I'm not completely sure on how @ would work with a case statement. @case $(HOSTARCH) in \ (*64) ln -s lib $(@D)/lib64;; \ (*) ln -s lib $(@D)/lib32;; \ esac > > Probably not really important, but what would HOSTARCH be on a MIP64 n32? > It doesn't look like that arch could be in the HOSTARCH as it's not in the sed filter list. > More importantly: it is possible that HOST_DIR/lib64 exists already but that > HOST_DIR ends up newer - for example because a new directory (e.g. sbin) was > created in it. Then the rule will be executed again, and a new symlink will be > created within the lib directory. So to avoid this, use ln -snf. > > To be sure, could you test with BR2_HOST_DIR set to somewhere else and also > rebuilding? Tested the ln -snf and the use of the alternate BR2_HOST_DIR. Looks good. > > Regards, > Arnout > >> + (*) ln -s lib $(@D)/lib32;; \ >> + esac >> + >> # Populating the staging with the base directories is handled by the skeleton package >> $(STAGING_DIR): >> @mkdir -p $(STAGING_DIR) >> > > -- > 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
On 04-10-17 23:28, Matthew Weber wrote: > Arnout, > > On Wed, Oct 4, 2017 at 3:37 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >> Hi Matt, >> >> On 04-10-17 14:41, Matt Weber wrote: [snip] >>> +$(HOST_DIR)/lib: $(HOST_DIR) >>> + @mkdir -p $@ >>> + case $(HOSTARCH) in \ >> >> Better put @ in front here. >> >>> + (*64) ln -s lib $(@D)/lib64;; \ > > So like the following but not the ln lines? I'm not completely sure > on how @ would work with a case statement. > @case $(HOSTARCH) in \ > (*64) ln -s lib $(@D)/lib64;; \ > (*) ln -s lib $(@D)/lib32;; \ > esac Yes indeed. The @ is taken away by make, the rest of the line (which in this case is 4 lines because of the \) is passed to shell and interpreted there. Make syntax is quite crazy :-) Regards, Arnout [snip]
diff --git a/Makefile b/Makefile index 9b09589..601de1d 100644 --- a/Makefile +++ b/Makefile @@ -542,7 +542,7 @@ endif .PHONY: dirs dirs: $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \ - $(HOST_DIR) $(HOST_DIR)/usr $(BINARIES_DIR) + $(HOST_DIR) $(HOST_DIR)/usr $(HOST_DIR)/lib $(BINARIES_DIR) $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG) $(MAKE1) $(EXTRAMAKEARGS) HOSTCC="$(HOSTCC_NOCCACHE)" HOSTCXX="$(HOSTCXX_NOCCACHE)" silentoldconfig @@ -565,6 +565,13 @@ sdk: world $(HOST_DIR)/usr: $(HOST_DIR) @ln -snf . $@ +$(HOST_DIR)/lib: $(HOST_DIR) + @mkdir -p $@ + case $(HOSTARCH) in \ + (*64) ln -s lib $(@D)/lib64;; \ + (*) ln -s lib $(@D)/lib32;; \ + esac + # Populating the staging with the base directories is handled by the skeleton package $(STAGING_DIR): @mkdir -p $(STAGING_DIR)
Discovered the issue on a RHEL7.4 machine where the cmake build dynamically selected HOST_DIR/lib64 as the installation path for the lzo2 library. Fixes failures like the following: host-mtd http://autobuild.buildroot.net/results/d31/d31581d2e60f35cf70312683df99c768e2ea8516/ host-squashfs http://autobuild.buildroot.net/results/d9c/d9c95231ac774ed71580754a15ebb3b121764310/ Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> --- Changes [Yann v2 -> v3 - Updated hostarch logic to check for 64bit in the name and if present create link. This supports all archs vs just x86. v1 -> v2 - Correct the condition used to determine host arch. (Previously used the target arch check) --- Makefile | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)