| Message ID | 1429635352-14756-1-git-send-email-yann.morin.1998@free.fr |
|---|---|
| State | Accepted |
| Headers | show |
Dear Yann E. MORIN, On Tue, 21 Apr 2015 18:55:52 +0200, Yann E. MORIN wrote: > 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. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > > --- > changes v3 -> v4: > - nothing, just rebased on top of master I've applied, even though I'm not terribly happy with the huge amount of complex shell code being added. This gconv stuff is already calling a shell script to recreate the gconv-modules file. Maybe we should just move all this logic to a separate shell script, in which we could use functions and so on? I've tried to think a bit about writing all of this in make, but it isn't trivial at all. Thomas
Thomas, All, On 2015-04-22 22:48 +0200, Thomas Petazzoni spake thusly: > On Tue, 21 Apr 2015 18:55:52 +0200, Yann E. MORIN wrote: > > 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. > > > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > > > > --- > > changes v3 -> v4: > > - nothing, just rebased on top of master > > I've applied, even though I'm not terribly happy with the huge amount > of complex shell code being added. This gconv stuff is already calling > a shell script to recreate the gconv-modules file. Maybe we should just > move all this logic to a separate shell script, in which we could use > functions and so on? Yes, that's a good idea. I've put it on my ever-growing TODO-list. ;-) > I've tried to think a bit about writing all of this in make, but it > isn't trivial at all. Nah, it's not. I tried a bit too, but promptly aborted, to keep using shell stuff. Thanks! :-) Regards, Yann E. MORIN.
diff --git a/toolchain/toolchain.mk b/toolchain/toolchain.mk index 3f9900b..0a35909 100644 --- a/toolchain/toolchain.mk +++ b/toolchain/toolchain.mk @@ -17,28 +17,38 @@ 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)found_gconv=no; \ + for d in $(TOOLCHAIN_EXTERNAL_PREFIX) ''; 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
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. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- changes v3 -> v4: - nothing, just rebased on top of master Changes v2 -> v3: - use TOOLCHAIN_EXTERNAL_PREFIX instead of computing it again Changes v1 -> v2: - also handle the case where the gconv modules list is specified --- toolchain/toolchain.mk | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-)