LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-27-2019, 11:32 AM   #1
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Rep: Reputation: Disabled
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?
 
Old 08-27-2019, 12:16 PM   #2
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 185

Rep: Reputation: 112Reputation: 112
Did you remember to also upgrade glibc-i18n?

Even if you did, just try reinstall it.
 
1 members found this post helpful.
Old 08-27-2019, 01:12 PM   #3
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Original Poster
Rep: Reputation: Disabled
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.
 
Old 08-27-2019, 01:22 PM   #4
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 185

Rep: Reputation: 112Reputation: 112
I think your locale name should be fr_FR.utf-8, not fr_FR.utf8 ...
 
Old 08-27-2019, 02:10 PM   #5
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Original Poster
Rep: Reputation: Disabled
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.
 
Old 08-27-2019, 02:40 PM   #6
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 185

Rep: Reputation: 112Reputation: 112
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.
 
Old 08-27-2019, 05:51 PM   #7
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Original Poster
Rep: Reputation: Disabled
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.
 
Old 08-27-2019, 06:17 PM   #8
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 185

Rep: Reputation: 112Reputation: 112
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.
 
Old 08-28-2019, 08:52 AM   #9
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,591

Rep: Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167Reputation: 2167
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'
Quote:
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'
Quote:
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
Code:
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
Code:
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
 
Old 08-31-2019, 04:36 PM   #10
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Original Poster
Rep: Reputation: Disabled
Looks like a PEBKAC case, not surprisingly. I probably borked an update, as I had this symlink in /lib64:
Code:
/lib64/ld-linux-x86-64.so.2 -> ld-2.29.so
Instead of:
Code:
/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:
Code:
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.

Last edited by Didier Spaier; 08-31-2019 at 04:37 PM.
 
Old 09-01-2019, 02:39 PM   #11
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,674

Rep: Reputation: 885Reputation: 885Reputation: 885Reputation: 885Reputation: 885Reputation: 885Reputation: 885
Quote:
Originally Posted by Didier Spaier View Post
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).
 
1 members found this post helpful.
Old 09-02-2019, 09:14 AM   #12
bormant
Member
 
Registered: Jan 2008
Posts: 401

Rep: Reputation: 223Reputation: 223Reputation: 223
Quote:
Originally Posted by ehartman View Post
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
Code:
$ 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*/.

Last edited by bormant; 09-02-2019 at 09:17 AM.
 
1 members found this post helpful.
Old 09-02-2019, 05:15 PM   #13
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Original Poster
Rep: Reputation: Disabled
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.

Last edited by Didier Spaier; 09-03-2019 at 06:25 AM.
 
Old 09-03-2019, 05:57 AM   #14
GazL
LQ Veteran
 
Registered: May 2008
Posts: 5,802

Rep: Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720Reputation: 3720
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.

Last edited by GazL; 10-14-2019 at 10:18 AM.
 
3 members found this post helpful.
Old 09-03-2019, 06:37 AM   #15
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Original Poster
Rep: Reputation: Disabled
GazL: thanks, that's a really useful utility!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
cannot lock locale archive "/usr/lib64/locale/locale-archive": Permission denied when building Multilib Cross Linux from Scratch Gunnersky2002 Linux - Software 2 06-13-2018 09:28 AM
[SOLVED] $LANG per user doesn't obey the global $LANG set in /etc/profile.d/lang.sh me_h Slackware 23 11-20-2016 07:28 AM
LC_* localization variables ikinnu Linux - Software 2 09-13-2008 10:02 AM
What is the use of lang in <head lang=''> tooparam Programming 2 02-01-2006 05:55 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:58 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration