toolchain: fix installing gconv libs with multi-arch toolchain
PATCH v2 1/1 toolchain: fix installing gconv libs with multi-arch toolchain
For a multi-arch toolchain, gconv modules are in a sub-directory named after the machine gcc targets. This is the case, for example, for the Linaro ARM 2014.09 toolchain, which has the gconv modules in (relative to the sysroot):
/usr/lib/arm-linux-gnueabihf/gconv
while the Sourcery CodeBench ARM 2014.05 (non-multi-arch) has them in:
/usr/lib/gconv
So, to catter for both cases, search both paths. We want to favour the machine-specific gconv modules over potentially existing "generic" ones, so we first search that (if it exists) and fallback to looking in the generic location.
---
Changes v1 -> v2:
- also handle the case where the gconv modules list is specified
---
Notes: I'm not too happy about the use of "gcc -dumpmachine", but that's the only solution I found that worked on my use-case. I tried duplicating the ARCH_SUBDIR trick from toolchain-external, but that did not work...
--- toolchain/toolchain.mk | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)
toolchain/toolchain.mk +19 -8
@@ -17,28 +17,39 @@ endif ifeq ($(BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_COPY),y) GCONV_LIBS = $(call qstrip,$(BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_LIST)) define COPY_GCONV_LIBS - $(Q)if [ -z "$(GCONV_LIBS)" ]; then \ - $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/gconv/gconv-modules \ - $(TARGET_DIR)/usr/lib/gconv/gconv-modules; \ - $(INSTALL) -m 0644 $(STAGING_DIR)/usr/lib/gconv/*.so \ + $(Q)machine=$$($(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS) -dumpmachine); \ + found_gconv=no; \ + for d in $${machine} ''; do \ + [ -d "$(STAGING_DIR)/usr/lib/$${d}/gconv" ] || continue; \ + found_gconv=yes; \ + break; \ + done; \ + if [ "$${found_gconv}" = "no" ]; then \ + printf "Unable to find gconv modules\n" >&2; \ + exit 1; \ + fi; \ + if [ -z "$(GCONV_LIBS)" ]; then \ + $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/$${d}/gconv/gconv-modules \ + $(TARGET_DIR)/usr/lib/gconv/gconv-modules && \ + $(INSTALL) -m 0644 $(STAGING_DIR)/usr/lib/$${d}/gconv/*.so \ $(TARGET_DIR)/usr/lib/gconv \ || exit 1; \ else \ for l in $(GCONV_LIBS); do \ - $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/gconv/$${l}.so \ + $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/$${d}/gconv/$${l}.so \ $(TARGET_DIR)/usr/lib/gconv/$${l}.so \ || exit 1; \ - $(TARGET_READELF) -d $(STAGING_DIR)/usr/lib/gconv/$${l}.so |\ + $(TARGET_READELF) -d $(STAGING_DIR)/usr/lib/$${d}/gconv/$${l}.so |\ sort -u |\ sed -e '/.*(NEEDED).*\[\(.*\.so\)\]$$/!d; s//\1/;' |\ while read lib; do \ - $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/gconv/$${lib} \ + $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/$${d}/gconv/$${lib} \ $(TARGET_DIR)/usr/lib/gconv/$${lib} \ || exit 1; \ done; \ done; \ ./support/scripts/expunge-gconv-modules "$(GCONV_LIBS)" \ - <$(STAGING_DIR)/usr/lib/gconv/gconv-modules \ + <$(STAGING_DIR)/usr/lib/$${d}/gconv/gconv-modules \ >$(TARGET_DIR)/usr/lib/gconv/gconv-modules; \ fi endef
Signature · 1 line
1.9.1
PATCH v2 1/1 toolchain: fix installing gconv libs with multi-arch toolchain
Dear Yann E. MORIN,
toolchain/toolchain.mk endif · line 20
Quoted 13 lines · Yann E. MORIN
toolchain/toolchain.mk +1
-4@@ -17,28 +17,39 @@ endif ifeq ($(BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_COPY),y) GCONV_LIBS = $(call qstrip,$(BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_LIST)) define COPY_GCONV_LIBS - $(Q)if [ -z "$(GCONV_LIBS)" ]; then \ - $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/gconv/gconv-modules \ - $(TARGET_DIR)/usr/lib/gconv/gconv-modules; \ - $(INSTALL) -m 0644 $(STAGING_DIR)/usr/lib/gconv/*.so \ + $(Q)machine=$$($(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS) -dumpmachine); \
Unless I'm mistaken, this piece of code copying gconv libraries is used for both the internal and external toolchain backends, no? If that's the case, then using TOOLCHAIN_EXTERNAL_* here seems wrong, no?
And indeed, the resulting code is not really nice. For sure not worse than the average toolchain-external.mk code :-/
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/1 toolchain: fix installing gconv libs with multi-arch toolchain
Thomas, All,
On 2015-03-08 22:48 +0100, Thomas Petazzoni spake thusly:
Quoted 11 lines · Yann E. MORIN
Quoted 10 lines
toolchain/toolchain.mk +0
-1@@ -17,28 +17,39 @@ endif ifeq ($(BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_COPY),y) GCONV_LIBS = $(call qstrip,$(BR2_TOOLCHAIN_GLIBC_GCONV_LIBS_LIST)) define COPY_GCONV_LIBS - $(Q)if [ -z "$(GCONV_LIBS)" ]; then \
Quoted 8 lines
toolchain/toolchain.mk endif · line 20
Quoted 4 lines
toolchain/toolchain.mk +1
-3- $(INSTALL) -m 0644 -D $(STAGING_DIR)/usr/lib/gconv/gconv-modules \ - $(TARGET_DIR)/usr/lib/gconv/gconv-modules; \ - $(INSTALL) -m 0644 $(STAGING_DIR)/usr/lib/gconv/*.so \ + $(Q)machine=$$($(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS) -dumpmachine); \Unless I'm mistaken, this piece of code copying gconv libraries is used for both the internal and external toolchain backends, no? If that's the case, then using TOOLCHAIN_EXTERNAL_* here seems wrong, no?
Absolutely.
In the meantime, I found out that I could re-use an existing variable, TOOLCHAIN_EXTERNAL_PREFIX which contains exactly what I expected "gcc -dumpmachine" to return. So I've switched to using that, and it "fixes" the use-case for internal toolchains as well as a side effect.
I'll resubmit later today...
Quoted 2 lines
And indeed, the resulting code is not really nice. For sure not worse than the average toolchain-external.mk code :-/
Meh... :-]
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'