Reprise du message précédent :
bizarre que ce soit passé bobor...  
 
j'avais mis longtemps a trouvé ca...
 
superX> tu fais une installe neuve la ? car par defo elles sont en C les locales... par contre si tu as changé pour mettre en fr_FR ben tu fais la manip inverse

 
Oui mais c'est moins marrant. Je prend quel stage 3 alors?
 

 
Déja testé, aucune optimzation, meme résultat

bon je viens de faire un petit test tout de même dans le doute:
perl --help
il me dit que setting locale failed
check que locale settings fr_FR installé
falling back to the standard locale "C"
 
Donc effectivement fr_FR n'est pas supporté mais il me met automatiquement la locale "C". C'est le principal. Et je n'ai pas eu de problème à la compil

 
j'ai rien changé. C'est une install neuve oui

si ça peut aider j'ai pris la version 1.4 (répertoire 1.4 et non 1.4beta) sur metalab.unc.edu

'tend , j'ai unseté tous les LC , je vais voir

la modif sur les locales que j'ai effectuée (mais avant le bootstrap !!!)
 
 

par contre je comprends pourquoi vi n'est pas l'editeur de base : je suis tout perdu avec nano

et le coup des unset a marché !!  yeeeeeeeees !

je vais m'essayer le usermode-sources , je sais pas trop ce qu'apporte le patch mais c'est pour l'exotisme

j'ai pas trop compris le usermode mais il semblerait que c'est une sorte de chroot. Par contre le gentoo-sources est pas mal:
grsecurity, htb, patch ac....
 
je te conseille plutot celui-ci

 
ok je vais essayé celui de gentoo alors.
 
parcontre j'ai pas l'intention de me taper un menuconfig. Ca ne pose aucun soucis particulier si je recupere le .config de mon 2.4.17 ?

si car le 2.4.19 n'aime pas les .config des versions antérieures
 
plusieurs s'y sont piqué avant toi...

bobor t'as modif sur les lc n'est pas celle dont je parle... toi tu as fait la modif pour ne compiler que ta locale a toi dans la glibc
 
celle dont je parle c les LC_ALL and co qui permettent de config la langue de ton systeme

ok
 
par contre lors de la compil de libgtk+-1.2 , j'ai eu le problème sur les locales. Chacun son tour.
 
J'ai fais unset et je vois. C'est bon ou c'est unset qqchose?

unset LC_COLLATE LC_CTYPE etc....

j'ai poussé la chose jusqu'a virer LANG et LANGUAGE mais je sais pas si c'est une bonne idée ...

je comprends pas trop cette commande
 
tu la fais en ligne de commande ou dans un fichier source?
où je peux trouver les unset à faire car je ne vais pas les inventer
 
sinon mon problème c'est Xsetlocale: undefined error

en ligne de commande et tu les reperes avec :  
 
set | grep "^LC"

ca a marché (seulement avec les LC)
 
par contre j'ai désactivé le support nls dans USE et je me demande si j'ai bien fait.
 
QQ'un pourrait-il me faire un petit cours sur les locale afin que de comprendre tout ce merdier
 
Si gcc ne supporte pas la fr_FR qu'est-ce que cela implique? c'est seulement pour les outils de correction orthographique? le clavier?

là je sais pas trop

La librairie locale(7) utilisée par la librairie C se sert de variables
d'environnement pour définir les préférences linguistiques et nationales
LC_COLLATE  équivalence de caractères pour les comparaisons.
(ex: æ peut être équivalent à ae)
LC_CTYPE    caractères affichables
LC_MONETARY monnaie utilisée
LC_MESSAGES langue des messages
LC_TIME     format de la date
LC_ALL      valeur par défaut des variables précedentes
LANG        surpasse les variables précédentes.

bon j'ai réactivé nls au cas où car je sens que je vais un système US/FR avec toutes ces manips et c'est reparti avec un
emerge --emptytree (pour être sûr)

http://www.freenix.fr/unix/linux/H [...] WTO-6.html
 
Les locales, sous Linux, ça va par défaut dans /usr/lib/locale,
et ça contient de quoi préciser entre autres le format des
nombres (LC_NUMERIC), les retours des fonctions ctype (isalpha etc) (LC_CTYPE), le format des sommes d'argent (LC_MONETARY), le format des dates (LC_TIME) et encore d'autres détails. Sur certains Unix, il y a aussi LC_MESSAGES, qui contient les messages de l'OS dans la langue choisie par la variable d'environnement LC_MESSAGES. Pas sous Linux.  Sous Linux, c'est nls qui fait ça, et de fait, nls gêre un fichier qui est dans /etc/locale/. (NDG : De nos jours, ils se trouvent plutôt dans /usr/lib/locale)
D'où l'embrouille. Ils auraient mis ça dans /usr/lib/ nls, comme tout le monde, ça aurait evite la confusion. Mais bon.

 
c'est fou qu'un truc aussi minime puisse bloquer une compil de la sorte!
 
sinon tu sais dans quel fichier de config on les déclare lors du boot? (j'anticipe sur le prochain boot sur gentoo )
 
sinon en locale non fr on aura pas d'accent si je comprends bien. Mais je pense que c'est quand même indépendant du clavier (du moins j'espère!)

sur gentoo je sais pas trop , c'est la 1ere que je compil'  , sinon à priori dans /etc/profile.env ?

sur le howto il disent que pour valider le fr il faut aller dans des sous-rep des sources de la libc et faire des make french
 
est-ce que cela marche sous gcc 3.2??? ce serait bien que kylourne vienne nous en dire un peu plus puisqu'il a appronfondi le sujet
 
ceci dit les messages en anglais me gêne pas si j'ai bien mes accents sur le clavier!

sur  mdk c'est dans /etc/sysconfig/i18n

vu
 
bon on verra bien au résultat
 
toujours dans le menuconfig ou tu compiles?

j'en ai profité pour faire un emerge search i18
 
il y a i18n-langtags: RFC3066 language tag handling for perl
et après plein de i18 pour kde (mais moi je me mets sous gnome)
 
le premier me tente bien

j'ai quand meme utilisé le config du 2.4.17 , j'ai jeté un oeil aux differents menus pour voir un peu quand meme , surtout qu'apres que la compil des modules se soit plantée sur un aic7xxx , là c'est reparti et ca se passe bien !

tu as bien présisé les native language?

ce qu'il faut

la compil de cet aic7xxx s'etant reproduite , je devrais apprendre à lire plus attentivement les msg d'erreurs : il manquait yacc  
 
pour l'instant , à part qq merdouilles de ce style , la beta à l'air de bien se passer.  J'attends quand meme de l'achever avant de me prononcer

?? j'ai pas yacc
 
mais je n'ai pas compilé ce module

yacc est un parser , pas un module

je parlais du module aicxxx !
 
kernel non monolytique. J'ai juste mis ext3 dans le kernel pour être sûr

t'as compilé un XFree ? il faut combien de temps à peu pres ?

bah en fait j'en suis à l'étape emerge fcron mais il y a xfree en dépendance...(je sais pas pourquoi)
 
donc ça compile...
xfree seul a du durer 2 à 3 heures, mais il y a aussi des lib gtk.... et je viens de relancer un emerge --emptyfree il y 30 minutes

c'est censé faire quoi un --emptyfree ?

ça considère que tu ne l'as pas installé donc ça recompile tout. En fait c'est utile quand tu changes tes varirables USE pour mettre tous tes packages en conformité avec ta config.
 
dans mon cas j'ai rajouté nls donc pour être sûr...
 
imagine un emerge -u world --emptyfree
tout est à jour! (à lancer avant de partir en WE)