I describe the current situation:
1) user enables locale support (BR2_TOOLCHAIN_BUILDROOT_LOCALE);
2) user optionally can set custom list of locales (BR2_GENERATE_LOCALE).
The option "BR2_GENERATE_LOCALE" is handled in "package/uclibc/
uclibc.mk":
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,$(UCLIBC_GENERATE_LOCALES),\
$(firstword $(subst .,$(space),$(locale))))
endif
...
define UCLIBC_LOCALE_CONFIG
...
$(call KCONFIG_ENABLE_OPT,UCLIBC_BUILD_MINIMAL_LOCALE,$(@D)/.config)
$(call KCONFIG_SET_OPT,UCLIBC_BUILD_MINIMAL_LOCALES,"$(UCLIBC_LOCALES)",$(@D)/.config)
...
endef
We can see that with empty list buildroot passes "en_US" to uClibc-ng.
The system library makefile handles option the following way (extra/locale/Makefile.in):
$(locale_OUT)/wctables.h: $(locale_OUT)/gen_wctype
@$(disp_gen)
$(Q)for locale in $(call qstrip,$(UCLIBC_BUILD_MINIMAL_LOCALES)) en_US en_GB; do \
$< $(FLAG-locale-verbose) $$locale > $@ || \
$< $(FLAG-locale-verbose) $$locale.UTF-8 > $@ || \
$< $(FLAG-locale-verbose) $$locale.iso8859-1 > $@ && break; \
done
The program "gen_wctype" receives locale name as command line parameter.
That application call the function setlocale() inside it.
Some time ago that call was disabled to workaround bug with locales.
That's the reason for the absence of problems in the past.
Changes in the last release return this call.