[SOLVED] can't set the locale; make sure $LC_* and $LANG are correct

Hello,

This error message is displayed when typing "man <something>".

I get also error messages like:
setlocale: LC_TIME: cannot change locale (fr_FR.utf8)
when running installpkg.

This is since I mistakenly upgraded glibc on one of my systems (based on Slackware version 14.2).

I reinstalled all stock Slackware glibc-* packages version 2.23 using upgradepkg to no avail.

I didn't notice other issues than breaking localization though.

Any clue?

Did you remember to also upgrade glibc-i18n?

Even if you did, just try reinstall it.

I have done that several times and just did it again, to no avail. Before someone asks, I have LANG set to fr_FR.utf8, as previously and as in my other systems on the same laptop. The only LC_* setting is LC_COLLATE, set to C.

I think your locale name should be fr_FR.utf-8, not fr_FR.utf8 ...

No, it works as is with other systems, and this setting didn't change since years. You can check that it is understood by glibc as it's in the output of locale -a.

I've use for years "pl_PL.UTF-8", and as example in /etc/profile.d/lang.sh is "en_US.UTF-8". Maybe give a try to "fr_FR.UTF-8".

You can also try fresh login shell, maybe some environment variables are broken now.

Other possibility is that in memory is OLD glibc and it try open OLD already deleted locale file. This need reboot as glibc is used by almost all binaries.

I did more web searching, to no avail: there are plenty of answers but suggesting to run utilities found in other distributions like localectl, localegen, dpkg-reconfigure locales.

I also added fr_FR8 to the archive. I checked that LOCPATH be not set.

Still no luck, so far.

You may try set different utf-8 locale and check if it also cause errors. This can restrict problem to your locale or libraries/tools.

I have often wondered about the setting of locale.
Here, I use 'export LANG=en_AU.UTF-8' in /etc/profile.d/lang.sh
This accords with 'man setlocale'

A locale name is typically of the form language[_territory][.codeset][@modifier], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set or encoding identifier like ISO-8859-1 or UTF-8.

According to 'man 7 locale'

ENVIRONMENT The following environment variable is used by newlocale(3) and setlocale(3), and thus affects all unprivileged localized programs: LOCPATH A list of pathnames, separated by colons (':'), that should be used to find locale data. If this variable is set, only the individual compiled locale data files from LOCPATH and the system default locale data path are used; any available locale archives are not used (see localedef(1)). The individual compiled locale data files are searched for under subdirectories which depend on the currently used locale. For example, when en_GB.UTF-8 is used for a category, the following subdirectories are searched for, in this order: en_GB.UTF-8, en_GB.utf8, en_GB, en.UTF-8, en.utf8, and en.

On this Slackware64 -current install, I see

bash-5.0$ ls /usr/lib64/locale/ | grep -e en_AU -e fr_FR
en_AU/
en_AU.utf8/
fr_FR/
fr_FR.utf8/
fr_FR\@euro/

so using fr_FR.utf8 is correct and perhaps more efficient.

The message 'setlocale: LC_TIME: cannot change locale (fr_FR.utf8)' suggests that the required locale files are not being found. As @Labinnah points out, the required files are supplied in the glibc-i18n package.
Maybe the output of 'localedef --help' will give a clue. That will show the default paths. Here I see

bash-5.0$ localedef --help | grep -A2 System
System's directory for character maps : /usr/share/i18n/charmaps
		       repertoire maps: /usr/share/i18n/repertoiremaps
		       locale path    : /usr/lib64/locale:/usr/share/i18n

Looks like a PEBKAC case, not surprisingly. I probably borked an update, as I had this symlink in /lib64:

/lib64/ld-linux-x86-64.so.2 -> ld-2.29.so

Instead of:

/lib64/ld-linux-x86-64.so.2 -> ld-2.23.so

upgradepkg glibc-solibs-2.23-x86_64-4_slack14.2.txz took care of that.

Incidentally I realized that upgrade glibc-solibs does not remove the shared libraries /lib64/<library_name><version>.so shipped in the previous glibc-solibs package:

didier[~]$ ls -l /lib64/*2.29*
-rwxr-xr-x 1 root root  191176 févr. 16  2019 /lib64/ld-2.29.so
-rwxr-xr-x 1 root root   16192 févr. 16  2019 /lib64/libBrokenLocale-2.29.so
-rwxr-xr-x 1 root root   23336 févr. 16  2019 /lib64/libanl-2.29.so
-rwxr-xr-x 1 root root 2207864 févr. 16  2019 /lib64/libc-2.29.so
-rwxr-xr-x 1 root root   48880 févr. 16  2019 /lib64/libcrypt-2.29.so
-rwxr-xr-x 1 root root   18816 févr. 16  2019 /lib64/libdl-2.29.so
-rwxr-xr-x 1 root root 1446248 févr. 16  2019 /lib64/libm-2.29.so
-rwxr-xr-x 1 root root  186536 févr. 16  2019 /lib64/libmvec-2.29.so
-rwxr-xr-x 1 root root  115696 févr. 16  2019 /lib64/libnsl-2.29.so
-rwxr-xr-x 1 root root   41656 févr. 16  2019 /lib64/libnss_compat-2.29.so
-rwxr-xr-x 1 root root   41176 févr. 16  2019 /lib64/libnss_db-2.29.so
-rwxr-xr-x 1 root root   30656 févr. 16  2019 /lib64/libnss_dns-2.29.so
-rwxr-xr-x 1 root root   64384 févr. 16  2019 /lib64/libnss_files-2.29.so
-rwxr-xr-x 1 root root   27112 févr. 16  2019 /lib64/libnss_hesiod-2.29.so
-rwxr-xr-x 1 root root   55648 févr. 16  2019 /lib64/libnss_nis-2.29.so
-rwxr-xr-x 1 root root   64976 févr. 16  2019 /lib64/libnss_nisplus-2.29.so
-rwxr-xr-x 1 root root  146816 févr. 16  2019 /lib64/libpthread-2.29.so
-rwxr-xr-x 1 root root  109000 févr. 16  2019 /lib64/libresolv-2.29.so
-rwxr-xr-x 1 root root   46344 févr. 16  2019 /lib64/librt-2.29.so
-rwxr-xr-x 1 root root   17960 févr. 16  2019 /lib64/libutil-2.29.so

I don't know the reason, but there should be one.

I mark this tread as SOLVED.

Originally Posted by Didier Spaier I don't know the reason, but there should be one.

That is because the system AS running still needs the older shared libraries, so newer versions are extracted (partly) into /lib64/incoming and later moved 1 dir UP into /lib64 and thus the libraries of the older package are not found anymore because this /lib64/incoming directory doesn't exist at the start of the upgrade. This is exactly WHY it's done that way, so at least everything linked to the older libraries still will run.
Only after a reboot you can optionally remove those older .so files (by hand, no "upgrade" operation will do so, just like libraries from aaa-elflibs are never removed).

Originally Posted by ehartman just like libraries from aaa-elflibs are never removed

The difference is in the cause.
Libraries from aaa_elflibs also sitting in mother's packages, so removing aaa_elflibs doesn't remove libraries from mother's installed packages, but remove others.
Libraries from glibc{,-solibs} sitting inside package in temporary path lib*/incoming/*.so

$ grep incoming /var/log/packages/glibc-*

and moved to final place with doinst.sh install script (/var/log/scripts/glibc-*). So removepkg knows about lib*/incoming/*.so names (from /var/log/packages/glibc-*), but not about final names in lib*/.

Thanks ehartman and Serg.

I removed all the files in /lib64/ coming from glibc-2.29 knowing that they weren't linked to by any software in the system in concern.

If you need any help with clean-up this script might help identify what needs removing. You'll get a lot of false positives and the "prune" list will need adjusting as I've not maintained it in a while, but it's a place to start.

It only lists stuff, the script takes no actions itself.


edit:
heh, I just discovered I have a lib64/libcidn-2.27.so still lurking on my '64-current' system. Show's how long it's been since I last ran unmanaged.

GazL: thanks, that's a really useful utility!