Skip to contentSkip to conversation

Fix locale generation with uClibc, and related improvements

PATCH New Thomas Petazzoni 2 participants 6 messages Nov 13, 2014 – Nov 21, 2014 Kbuild

lore
Share & tools
lore
#0 lore raw

cover Fix locale generation with uClibc, and related improvements

Hello,

This set of patches fix the locale generation with uClibc: without those fixes, the value in the BR2_GENERATE_LOCALE option is ignored due to a regression introduced by a rework of the main Makefile.

The most important patch is PATCH 2, which does the actual fix. PATCH 1 is a preparatory cleanup. PATCH 3 and 4 are additional minor improvements to the BR2_GENERATE_LOCALE option logic.

I think this should be considered material for 2014.11.

Best regards,

Thomas

Thomas Petazzoni (4):
Makefile: use more sensible names for locale related variables
uclibc: do not use GENERATE_LOCALE
toolchain: do not allow BR2_GENERATE_LOCALE with musl
toolchain: do not allow locale generation when locale support is not
available

 Makefile                      | 10 +++++-----
 package/uclibc/uclibc.mk      |  6 ++++--
 toolchain/toolchain-common.in |  2 +-
 3 files changed, 10 insertions(+), 8 deletions(-)
Signature · 1 line
2.1.0
#1 lore raw

PATCH 1/4 Makefile: use more sensible names for locale related variables

The GENERATE_LOCALE variable is used for the qstripped version of BR2_GENERATE_LOCALE. It was used by both the glibc locale generation code (in the main Makefile), and by the uClibc logic in package/uclibc/uclibc.mk. However, since commit 33de7401701e5242196a86b0695ee4ae9a4c4082 ("Makefile: convert "target-generatelocales" to a hook"), this code has been moved around in the main Makefile, and the definition of GENERATE_LOCALE is now *after* uclibc.mk is included, and therefore this variable is always empty when uclibc.mk looks at it for its conditionals. Moreover, it is now only defined in the main Makefile is BR2_TOOLCHAIN_USES_GLIBC is 'y', which obviously isn't the case for uClibc toolchains.

Since it's anyway not very clear to have this variable shared between the glibc locale generation logic in the main Makefile and the uClibc configuration code in uclibc.mk, this commit:

- Renames the GENERATE_LOCALE variable in the main Makefile to GLIBC_GENERATE_LOCALES.

- Renames the GENERATE_LOCALES hook to GENERATE_GLIBC_LOCALES, since it's specific to glibc.

The fix for the uClibc case is part of a followup commit.

---
 Makefile | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Makefile +5 -5
index 471edf9..41fd91a 100644
@@ -514,13 +514,13 @@ endif
 # not have them (Linaro toolchains), we use the ones available on the
 # host machine.
 ifeq ($(BR2_TOOLCHAIN_USES_GLIBC),y)
-GENERATE_LOCALE = $(call qstrip,$(BR2_GENERATE_LOCALE))
-ifneq ($(GENERATE_LOCALE),)
+GLIBC_GENERATE_LOCALES = $(call qstrip,$(BR2_GENERATE_LOCALE))
+ifneq ($(GLIBC_GENERATE_LOCALES),)
 TARGETS += host-localedef
 
-define GENERATE_LOCALES
+define GENERATE_GLIBC_LOCALES
 	$(Q)mkdir -p $(TARGET_DIR)/usr/lib/locale/
-	$(Q)for locale in $(GENERATE_LOCALE) ; do \
+	$(Q)for locale in $(GLIBC_GENERATE_LOCALES) ; do \
 		inputfile=`echo $${locale} | cut -f1 -d'.'` ; \
 		charmap=`echo $${locale} | cut -f2 -d'.' -s` ; \
 		if test -z "$${charmap}" ; then \
@@ -535,7 +535,7 @@ define GENERATE_LOCALES
 			$${locale} ; \
 	done
 endef
-TARGET_FINALIZE_HOOKS += GENERATE_LOCALES
+TARGET_FINALIZE_HOOKS += GENERATE_GLIBC_LOCALES
 endif
 endif
 
Signature · 1 line
2.1.0
#2 lore raw

PATCH 2/4 uclibc: do not use GENERATE_LOCALE

In reply to Thomas Petazzoni

Since commit 33de7401701e5242196a86b0695ee4ae9a4c4082 ("Makefile:
convert "target-generatelocales" to a hook"), the GENERATE_LOCALE variable is never defined when using uClibc. This means that setting any value to the BR2_GENERATE_LOCALE option had no effect for uClibc toolchains.

In this commit, we make sure the uclibc.mk logic re-creates its own qstripped version of BR2_GENERATE_LOCALE, in a variable called UCLIBC_GENERATE_LOCALES.

This fixes locale generation with uClibc in the internal toolchain backend.

---
 package/uclibc/uclibc.mk | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
package/uclibc/uclibc.mk +4 -2
index ce416dd..2d95ce1 100644
@@ -47,12 +47,14 @@ UCLIBC_KCONFIG_OPTS = \
 
 UCLIBC_TARGET_ARCH = $(call qstrip,$(BR2_UCLIBC_TARGET_ARCH))
 
-ifeq ($(GENERATE_LOCALE),)
+UCLIBC_GENERATE_LOCALES = $(call qstrip,$(BR2_GENERATE_LOCALE))
+
+ifeq ($(UCLIBC_GENERATE_LOCALES),)
 # We need at least one locale
 UCLIBC_LOCALES = en_US
 else
 # Strip out the encoding part of locale names, if any
-UCLIBC_LOCALES = $(foreach locale,$(GENERATE_LOCALE),\
+UCLIBC_LOCALES = $(foreach locale,$(UCLIBC_GENERATE_LOCALES),\
 		   $(firstword $(subst .,$(space),$(locale))))
 endif
 
Signature · 1 line
2.1.0
#3 lore raw

PATCH 3/4 toolchain: do not allow BR2_GENERATE_LOCALE with musl

In reply to Thomas Petazzoni

Generating locales is possible in two situations:

- With the internal toolchain backend, when the uClibc library is used. With uClibc, locales are generated at build time of the C library, so with uClibc it's only possible with the internal toolchain backend.

- With either the internal or external toolchain backend when the glibc library is used. With glibc, locales can be generated afterwards, using the host-localedef utility.

Until we had the musl C library supported in the internal toolchain backend, the condition: BR2_TOOLCHAIN_BUILDROOT || BR2_TOOLCHAIN_USES_GLIBC was correct to capture the above two situations. Now that we have musl support in the internal toolchain backend, then BR2_TOOLCHAIN_BUILDROOT is incorrect, and we should use BR2_TOOLCHAIN_BUILDROOT_UCLIBC instead.

Basic locale support in musl has appeared in musl 1.1.4, but we are not yet capable of generating the locale files for musl.

---
 toolchain/toolchain-common.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
toolchain/toolchain-common.in +1 -1
index 2dfaecc..683c143 100644
@@ -69,7 +69,7 @@ config BR2_GENERATE_LOCALE
 	string "Generate locale data"
 	default ""
 	depends on \
-		BR2_TOOLCHAIN_BUILDROOT      || \
+		BR2_TOOLCHAIN_BUILDROOT_UCLIBC || \
 		BR2_TOOLCHAIN_USES_GLIBC
 	help
 	  Generate support for a list of locales. Locales can be
Signature · 1 line
2.1.0
#4 lore raw

PATCH 4/4 toolchain: do not allow locale generation when locale support is not available

In reply to Thomas Petazzoni

When the C library being used is uClibc, the locale support can be disabled. In this case, it does not make sense to show the "Generate locales" option.

---
 toolchain/toolchain-common.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
toolchain/toolchain-common.in +1 -1
index 683c143..ad04d64 100644
@@ -69,7 +69,7 @@ config BR2_GENERATE_LOCALE
 	string "Generate locale data"
 	default ""
 	depends on \
-		BR2_TOOLCHAIN_BUILDROOT_UCLIBC || \
+		(BR2_TOOLCHAIN_BUILDROOT_UCLIBC && BR2_ENABLE_LOCALE) || \
 		BR2_TOOLCHAIN_USES_GLIBC
 	help
 	  Generate support for a list of locales. Locales can be
Signature · 1 line
2.1.0
#5 lore raw

cover Fix locale generation with uClibc, and related improvements

In reply to Thomas Petazzoni
Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,
This set of patches fix the locale generation with uClibc: without those fixes, the value in the BR2_GENERATE_LOCALE option is ignored due to a regression introduced by a rework of the main Makefile.

The most important patch is PATCH 2, which does the actual fix. PATCH 1 is a preparatory cleanup. PATCH 3 and 4 are additional minor improvements to the BR2_GENERATE_LOCALE option logic.

I think this should be considered material for 2014.11.

Committed series, thanks.

Signature · 1 line
Bye, Peter Korsgaard