# [Résolu][Encodage] pb UTF-8 depuis des màj / locale segfault

## Slashounet

Bonjour,

J'ai un serveur avec une Gentoo hardened qui tourne depuis longtemps, et je ne faisais pas trop de MàJ (juste le strict minimum). Ces dernières semaines, avec tous les messages liés à udev dans les emerge, j'ai décidé de mettre complètement à jour mon serveur histoire de ne pas avoir de mauvaise surprise.

J'ai donc passé pas mal de paquets au fur et à mesure, et depuis, j'ai des messages d'erreur qui apparaissent partout et qui semblent liés à l'encodage. Par exemple, lors que je fais un emerge j'ai régulièrement ce message durant la compilation :

```
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
```

Ou si je lance mutt :

```
pinentry-curses: no LC_CTYPE known - assuming UTF-8
```

Ensuite, évidemment tous les accents et les flèches des fils de discussion s'affichent n'importe comment.

Jusqu'à présent, mon système était en en_US.UTF-8, sans rien de plus (/etc/locale.gen) :

```
en_US.UTF-8 UTF-8
```

Et je n'avais pas positionné les variables LC_*. Dnas le doute, je vérifie ce que locale me renvoie, et là c'est le drame :

```
slash>~$locale

Segmentation fault

slash>~$
```

Je me suis dit qu'il y avait un petit souci aussi avec mon locale.gen, donc j'ai relancé un locale-gen, nouveau drame :

```
slash>~$su -

Password: 

-su: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory

-su: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

root>~$locale-gen

/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

 * Generating 1 locales (this might take a while) with 1 jobs

 *  (1/1) Generating en_US.UTF-8 ... [ !! ]

 * Generation complete

root>~$
```

Donc la génération ne se passe pas bien.

Et j'ai aussi essayé de lui ajouter à un moment ou un autre :

```
en_US ISO-8859-1

fr_FR.UTF-8 UTF-8

fr_FR@euro ISO-8859-15

fr_FR ISO-8859-1
```

(ça ne change évidemment rien, l'erreur apparait pour toutes les locales)

De là, je me suis dit qu'il y avait eu un souci avec la libc, gcc, ou un paquet lié. J'ai fait mes revdep-rebuild, j'ai recompilé mon système… sans succès. Franchement, je ne vois pas trop où regarder pour corriger ça, je tape peut-être complètement à côté. Je n'ai pas trop suivi l'actualité Gentoo, donc peut-être qu'il y a eu quelque chose sur le sujet qui est passé, dans tous les cas c'est sacrément gênant. 

Si vous avez une petite idée, je suis preneur.

/

----------

## boozo

'alute

Vu que tu déclenche un segfault en lançant #locale, c'est ta glibc qui a un pb vraisemblablement.

Si tu as fait de grosses màj : etc-update oublié voire gcc-config ou le profile incorrects ? (voir aussi les supports dans la nouvelle quenelle s'il ya lieu)

----------

## Slashounet

OK, alors j'ajoute un peu de contexte :

- pour la version de gcc, j'utilise gcc 4.6.3 (686-pc-linux-gnu-4.6.3 dans gcc-config -l). Effectivement, j'ai dû changer de version de gcc durant ces dernières semaines.

- pour le profil, j'utilise celui-ci : hardened/linux/x86

- pour la glibc, c'est la 2.15-r3 avec seulement le flag hardened.

- pour etc-update, il n'y a que mes fichiers de conf liés à la partie mail qui sont à mettre à jour.

Maintenant, je ne vois pas trop ce que je peux faire. Actuellement, un revdep-rebuild me donne juste mon postfix à recompiler. Ce serait intelligent de repasser à une version plus ancienne de gcc (4.5.4 ? plus ancienne ?) et/ou de la glibc (2.15-r2 ? 2.14.1-r3 ? plus ancienne ?), de tout recompiler avec ? Ou alors ce serait une cata ?

/

----------

## boozo

Je ne vois pas pourquoi ce devrait-être nécessaire ; ta conf n'a rien d'exotique donc autant essayer de trouver la cause.

Autres infos possibles dans les logs ?

Sinon qu'y a-t-il en variables dans ton /etc/env.d/02locale voire le(s) ~/.<shell>rc en fonction de ce(ux) que tu utilises.

Et est-ce que cela se produit dans tous les contextes i.e. en tty, sous X avec une console, etc ?

Edit: tant qu'on y est : poste le #emerge --info aussi ^^

----------

## Slashounet

Initialement, je n'avais strictement rien dedans, en cherchant sur le net je trouvais des lines conseillant de modifier le fichier. Et en fait, en passant par eselect, j'ai ça :

```
# Configuration file for eselect

# This file has been automatically generated.

LANG="en_US.UTF-8"

```

Pour ce qui est du shell, initialement, je n'avais aucune variable LC_* saisie, j'ai testé en positionnant ces variables dans mon .bashrc :

```
export LC_ALL="en_US.UTF-8"

export LANG="en_US.UTF-8"

export LC_CTYPE="en_US.UTF-8"
```

Et finalement j'ai tout commenté.

Sinon, je viens de remarquer ça (pas les mêmes messages) :

```
slash>~$su

Password: 

bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

root>slash$exit

slash>~$su -

Password: 

-su: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory

-su: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

root>~$
```

Ensuite, sur mon serveur, il n'y a pas de serveur X, donc je ne sais pas trop.

/

EDIT : le emerge --info

```
Portage 2.1.11.52 (hardened/linux/x86, gcc-4.6.3, glibc-2.15-r3, 2.6.39-gentoo-r3 i686)

=================================================================

System uname: Linux-2.6.39-gentoo-r3-i686-Intel-R-_Atom-TM-_CPU_Z530_@_1.60GHz-with-gentoo-2.1

KiB Mem:     1024168 total,     42128 free

KiB Swap:    2048280 total,   2011716 free

Timestamp of tree: Fri, 15 Mar 2013 02:15:01 +0000

ld GNU ld (GNU Binutils) 2.22

distcc 3.1 i686-pc-linux-gnu [enabled]

app-shells/bash:          4.2_p37

dev-java/java-config:     2.1.12-r1

dev-lang/python:          2.7.3-r2, 3.1.4-r3, 3.2.3

dev-util/cmake:           2.8.9

dev-util/pkgconfig:       0.28

sys-apps/baselayout:      2.1-r1

sys-apps/openrc:          0.11.8

sys-apps/sandbox:         2.5

sys-devel/autoconf:       2.69

sys-devel/automake:       1.9.6-r3, 1.10.3, 1.11.6

sys-devel/binutils:       2.22-r1

sys-devel/gcc:            4.3.6-r1, 4.4.7, 4.5.4, 4.6.3

sys-devel/gcc-config:     1.7.3

sys-devel/libtool:        2.4-r1

sys-devel/make:           3.82-r4

sys-kernel/linux-headers: 3.6 (virtual/os-headers)

sys-libs/glibc:           2.15-r3

Repositories: gentoo

ACCEPT_KEYWORDS="x86"

ACCEPT_LICENSE="* -@EULA dlj-1.1 Oracle-BCLA-JavaSE"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=i686 -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /etc/conf.d /etc/ntp.conf /etc/resolv.conf /etc/ssh /etc/sudoers /usr/share/gnupg/qualified.txt /var/bind"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"

CXXFLAGS="-O2 -march=i686 -pipe"

DISTDIR="/usr/portage/distfiles"

FCFLAGS="-march=i686 -O2 -pipe"

FEATURES="assume-digests binpkg-logs config-protect-if-modified distcc distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"

FFLAGS="-march=i686 -O2 -pipe"

GENTOO_MIRRORS="ftp://gentoo.imj.fr/pub/gentoo/ ftp://mirror.ovh.net/gentoo-distfiles/ http://mirrors.linuxant.fr/distfiles.gentoo.org/ http://mirror.ovh.net/gentoo-distfiles/ ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ ftp://mirrors.ipv6.linuxant.fr/distfiles.gentoo.org/ http://mirrors.ipv6.linuxant.fr/distfiles.gentoo.org/ http://gentoo.modulix.net/gentoo/ "

LANG="en_US.UTF-8"

LC_ALL="en_US.UTF-8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

MAKEOPTS="-j5"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --bwlimit=100"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY=""

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="X509 aalib acl acpi bash-completion berkdb bzip2 cacalib cli cracklib crypt cxx doc dri exif ftp gdbm gif gmp gnutls gpm hardened iconv ipv6 jpeg ldap man modules mudflap ncurses nls nptl openmp pam pax_kernel pcre pic png readline session sqlite ssl svg tcpd unicode urandom usb vim-syntax x86 zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="mouse keyboard evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en fr" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 intel mach64 mga nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa via vmware nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
```

----------

## boozo

... /me ne vois hélas rien de probant qui me saute aux yeux  :Sad: 

Tout semble ~à jours excepté la quenelle qui date un peu même en hardened-sources... (une raison ?)

Ce qui me gène le plus c'est le segfaut sur locale et le fait que locale-gen plante également pour les mêmes raisons probablement.

Tu as essayer de tracer ce qu'il se passe avec ? (ldd, gdb, ...)

Edit(s): Quel sont les flags actifs sur ta glibc stp ?

btw, pourquoi emerge --info renvois un LC_ALL définit alors que tu l'as recommenté ? tu as fait un env-update && source /etc/profile depuis avant de repasser dessus ?

----------

## xaviermiller

Pourrais-tu vérifier ton matériel, et principalement la RAM ? Autant être sûr et fermer progressivement toutes les portes.

----------

## Slashounet

Pour ma glibc, j'ai juste le flag hardened.

Tout à fait pour le kernel : la raison est que c'est mon serveur et que j'ai pour principe de ne pas trop toucher à ce qui fonctionne. Mais comme il y a eu cette histoire de changements avec udev 197 et la nécessité d'activer une option dans le noyau, je me suis dit qu'il fallait tout mettre à jour proprement avant. J'ai dans l'idée de passer au dernier stable dès que j'aurai résolu mon souci.

Pour ce qui est de vérifier mon matériel, oui, qu'est-ce qui parait pertinent comme information ? (et pour le coup, faudra attendre que je sois chez moi je pense, sauf si tu as des idées faisables en ssh sans accès physique)

/

----------

## boozo

 *Quote:*   

> Mais comme il y a eu cette histoire de changements avec udev 197 et la nécessité d'activer une option dans le noyau, je me suis dit qu'il fallait tout mettre à jour proprement avant.

 

Oui et non... ça peut dépendre des cas de figures : donc si je suis bien là tu as un kernel-2.6.39-r3 hardened sans devtmpfs et companie mais migré vers udev-197.x c'est çà ?

 :Question:  Tu as un /usr séparé (ou des options particulières en fstab) ?

----------

## Slashounet

En fait, la MàJ udev était bloquante, j'ai donc dû la faire en suivant les directives documentées (activation de devtmpfs dans le noyau, …) mais je n'ai pas de /usr séparé. De là, les autres MàJ ont pu aussi être faites, et j'ai eu le souci. Je me suis dit qu'il valait mieux résoudre ce souci avant de passer à un nouveau noyau, et je me suis avant tout assuré que mon serveur rebootait bien et que mes services tournaient correctement.

De là, j'ai tenté de bidouiller pour réparer le souci, mais la recompilation de la glibc n'a rien changé dirait-on. J'ai épuisé les pistes qui me venaient intuitivement, peut-être que vous aurez d'autres idées.

Ce qui est vraiment idiot de ma part, c'est d'avoir fait autant de MàJ plusieurs soirées étalées sur 3 ou 4 semaines. Du coup, c'est vraiment difficile d'identifier le moment où le souci est véritablement apparu. J'imagine que c'est venu avec la glibc / gcc, mais rien n'est sûr :\

/

----------

## nox23

que donne :

```

strace locale

```

si tu n'as pas strace : emerge -av strace

----------

## Slashounet

Voici la sortie de strace sur locate :

```
root@>$strace locale

execve("/usr/bin/locale", ["locale"], [/* 40 vars */]) = 0

brk(0)                                  = 0xb79ad000

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7825000

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/tls/i686/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/tls/i686/sse2", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/tls/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/tls/i686", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/tls/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/tls/sse2", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/tls", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/i686/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/i686/sse2", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/i686", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/sse2/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0/sse2", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/usr/include/gtk-2.0/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

stat64("/usr/include/gtk-2.0", 0xbfdb2b20) = -1 ENOENT (No such file or directory)

open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3

fstat64(3, {st_mode=S_IFREG|0644, st_size=49038, ...}) = 0

mmap2(NULL, 49038, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7819000

close(3)                                = 0

open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\246\1\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=1602736, ...}) = 0

mmap2(NULL, 1617404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb768e000

mprotect(0xb7812000, 4096, PROT_NONE)   = 0

mmap2(0xb7813000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x184) = 0xb7813000

mmap2(0xb7816000, 11772, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7816000

close(3)                                = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb768d000

set_thread_area({entry_number:-1 -> 6, base_addr:0xb768d6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0

mprotect(0xb7813000, 8192, PROT_READ)   = 0

mprotect(0xb7847000, 28672, PROT_READ|PROT_WRITE) = 0

mprotect(0xb7847000, 28672, PROT_READ|PROT_EXEC) = 0

mprotect(0xb784e000, 4096, PROT_READ)   = 0

mprotect(0xb7845000, 4096, PROT_READ)   = 0

munmap(0xb7819000, 49038)               = 0

brk(0)                                  = 0xb79ad000

brk(0xb79ce000)                         = 0xb79ce000

open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)

open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3

fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)

fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7824000

read(3, "# Locale name alias data base.\n#"..., 4096) = 2570

read(3, "", 4096)                       = 0

close(3)                                = 0

munmap(0xb7824000, 4096)                = 0

open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fec} ---

+++ killed by SIGSEGV +++

Segmentation fault
```

Je vais rentrer et j'aurai un accès physique au serveur. Je vais voir ce que je peux tester côté matériel. Pour la RAM, j'imagine que memtest fera l'affaire.

/

EDIT : j'ai édité la trace et mis la bonne

----------

## boozo

Il n'y a rien de malhabile dans ta façon de faire c'est juste que j'essaie aussi de comprendre ce qui pourrait causer cela.

J'ai parlé de /usr rapport au point de stockage des locales (/usr/share/i18n/locales/) en l'occurrence - c'est peut-être un peu tiré par les cheveux soit mais quand on ne voit rien on envisage aussi le plus improbable i.e. plus de place sur une partition séparée, droits insuffisants ou inadaptés dessus, etc   :Rolling Eyes: 

Autre hypothèse : distcc qui aurait pu compiler certains programmes avec des gcc ou des options différentes

Je suppose que tu as déjà vérifié mais les fichiers locale en_US existent bien ? (dans la foulée, colle nous quand même les fichers /etc/locale.gen ; 02locale et autres en lien des fois qu'il y ait une erreur dedans qui passe inapperçue)

Et tant que j'y pense aussi tu passes par "#su -" à chaque fois mais essaye quand même sans spécifier l'environnement voir si c'est différent en terme de comportement

ps: petite erreur de typo pour la trace, essayes plutôt sur locale-gen ou locale :p 

Edit:

```
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
```

Est-ce que ce fichier existe ?

----------

## Slashounet

iop,

Alors, en effet je m'étais planté en faisant le strace, j'ai corrigé et mis la bonne trace.

Ok, voici /etc/locale.gen :

```
# /etc/locale.gen: list all of the locales you want to have on your system

#<snip> comentaires

en_US.UTF-8 UTF-8

en_US ISO-8859-1

fr_FR.UTF-8 UTF-8

fr_FR@euro ISO-8859-15

fr_FR ISO-8859-1
```

Et /etc/env.d/02locale :

```
# Configuration file for eselect

# This file has been automatically generated.

LANG="en_US.UTF-8"
```

Concernant en_US, j'ai ça :

```
root>~$ls /usr/share/i18n/locales/en_US 

/usr/share/i18n/locales/en_US
```

Sinon, je viens de regarder dans /usr/lib/locale/ et je ne vois pas de fichier 'locale-archive' :\

Enfin, dernier point, l'hypothèse distcc m'intéresse : j'utilise effectivement distcc sur mes machines pour compiler les paquets sur mon serveur.

/

EDIT : c'est pire que ça, /usr/lib/locale/ est complètement vide.

----------

## boozo

mmmh ?! m'avais fait pensé à ce bug lié a glibc-omitfp au départ mais je n'en ai pas vu trace chez toi   :Confused:   C'est étrange... a moins que cela ne soit en lien avec le profile hardened pour glibc -> A vérifer

Peux-tu essayer en générant la locale en question avec liocaledef à la pace de locale-gen voir si c'est mieux ?

```
#localedef -c -i en_US -f UTF-8 en_US.UTF-8
```

Edit: Ah? trouvé un problème similaire avec truc il y a qq temps... ça se confirme peut-être   :Wink: 

----------

## Slashounet

 :Sad: 

```
root>~$localedef -c -i en_US -f UTF-8 en_US.UTF-8

Segmentation fault

root>~$
```

Je vais regarder cet autre lien.

/

----------

## boozo

*grmmll*   :Confused: 

Pour l'hypothèse distcc/ccache, ça dépend du sens que tu utilises si le serveur compile "pour lui-même" i.e. je ne pense pas que cela joue vraiment mais tu peux toujours désactiver distcc temporairement et lancer un oneshot sur glibc avant de retenter.

Pourtant ça colle assez bien avec le bug en question tes symptômes-là... mais si rien ne bouge qqsoit la façon de procéder pour contourner, il faudra peut-être se résigner à tester d'autres versions (up-down) de glibc voire prendre un binaire sur la tinderbox et repasser dessus ensuite pour espérer recaler les choses   :Rolling Eyes: 

Edit: En regardant un peu plus glibc chez moi, j'ai trouvé un vieux patch qui s'applique au configure sur la version et dans lequel on peut lire :

 */usr/portage/sys-libs/glibc/files/2.3.3/glibc-2.3.3-localedef-fix-trampoline.patch wrote:*   

> 
> 
> ```
>  # DP: Description: Fix localedef segfault when run under exec-shield,
> 
> ...

 

Je ne trouve pas de lien pertinent avec ces références chez nous donc ce doit-être upstream mais où   :Evil or Very Mad: 

Je vais regarder ce que je trouve avec cette piste

Edit2: ayé trouvé ^^ ça vient de chez deb ces ref. (#231438 ; #198099)

Alors vu que tu es en hardened avec pax_kernel, faudra p.e. voir en désactivant temporairement exec-shield si c'est lié ou non (i.e. #echo 0 > /proc/sys/kernel/exec-shield) et relancer locale-gen

----------

## Slashounet

Salut,

De bonnes nouvelles !

Suite à ta remarque sur distcc hier, je l'ai désactivé et j'ai recompilé la glibc sur mon serveur. Ce fut un peu long, mais à la fin, il a bien regénéré les locales sans souci. locale-gen fonctionne, et l'affichage des caractères unicode est revenu à la normale \o/ Ce qui fait que je n'ai pas regardé ce que tu as ajouté avec ton Edit. Maintenant que c'est résolu, j'aimerais tout de même comprendre vraiment le problème. Il semblerait donc que ce soit lié au fait que j'utilise toutes mes machines pour compiler, et dans ce cas précis ma machine fixe qui n'a pas la même version de gcc ni de la glibc.

Je vais tout de même regarder tes autres propositions, par acquis de conscience, mais dans tous les cas, merci beaucoup. Je n'aurais jamais pensé à désactiver distcc.

/

Edit : et le profil est différent aussi

----------

## boozo

Bien  :Smile:  content que tout rentre dans l'ordre sans plus de mal.

Inutile de regarder mes dernières notes qui anticipaient d'autres pistes pour balayer des hypothèses, là l'explication est assez claire et cohérente mais je te développerai ça un peu plus tard (pas trop de temps là).

----------

## boozo

Re-

alors le principe est simple tu déportes la compilation (totalement ou pour partie) sur d'autres machines et donc tu détournes leurs outils de compilation pour générer les bouts de codes que tu veux via un ordonnanceur.

Si les différents gcc utilisés à cette fin sont optimisés/paramétrés pour générer du code spécifique pour une architecture par exemple alors un bout de code de l'un assemblé ensuite avec celui d'un autre peuvent générer des comportement anormaux. Un exemple classique de ce cas de figure depuis gcc-4.3 par exemple est de l'utiliser en présence de march=native sur des machines avec des cpu différents en lieu et place d'options génériques et donc compatibles pour une architecture donné  :Wink: 

D'autres effets indésirables peut-être déclenchés de façon similaires s'il y a des écarts de versions majeures aussi (en caricaturant, utiliser un assemblage de code produit par un gcc-2 et un gcc-4) et des jeux d'intructions vraiment différents d'une machine à l'autre.

Après ce n'est pas non plus si contraignant que çà à utiliser mais Il faut être attentif aux options dès le départ sinon s'en souvenir si on ajoute/retranche des esclaves de compilation ; et essayer de conserver des toochain en phase de version ou au moins si possible, pas trop en décalage pour éviter ce genre de désagrément.

Edit: Tu penseras à coller un petit (résolu) à a fin stp ? merci ^^

----------

## Slashounet

OK, merci pour l'explication. Donc si je souhaite réutiliser distcc (super utile pour mon serveur), faut que je fasse un peu plus attention à ce qui est installé et utilisé sur mes autres machines, et il faut que j'adapte un peu les options pour éviter les mauvaises surprises.

Merci.

/

----------

## boozo

Oui c'est tout-à-fait çà   :Smile:   et si tu as des architectures différentes à ta disposition il faut te tourner du côté de crossdev

(/off d'ailleurs je me rends compte que j'aurais pu simplement t'indiquer au départ la référence sur la doc au lieu de la paraphraser en moins bien)

 *Quote:*   

> 5.  Troubleshooting
> 
> Some Packages Don't Use Distcc
> 
> As you emerge various packages, you'll notice that some of them aren't being distributed (and aren't being built in parallel). This may happen because the package's Makefile doesn't support parallel operations or the maintainer of the ebuild has explicitly disabled parallel operations due to a known problem.
> ...

 

----------

