What do I recompile?
declan.moriarty at ntlworld.ie
Wed Jul 9 05:58:30 PDT 2003
On Tue, Jul 08, 2003 at 10:03:32PM +0200, Erika Pacholleck enlightened us thusly
> Declan, I changed the order a bit.
> [08.07.2003] Declan. Moriarty <-- :
> > You have your finger on something.
> > root:/usr/lib/locale/en_GB#ls
> > LC_CTYPE LC_NUMERIC LC_TIME
> > Only 3 files. It seems I don't HAVE
> > /usr/lib/locale/en_GB/LC_MESSAGES :-O.
> This is wrong, definitly. A glibc-2.2.5 system will end up with at
> least 6 LC_XXX (there are more, around 10 or so) plus a dir
> LC_MESSAGES with 1 SYS_LC_MESSAGES file.
OK. I have used the original tarball (Stored on a cdrom). Maybe I should
get suspicious of that?
> What the hell is the /2 doing in that?
> Do you have a top dir called /2?
> Or did you do it to indicate a second run/system(/chance maybe?)
Congratulations for guessing. The disk was formatted when I was
crashtesting: I split it into 2'root' partitions which appear in each
system as /1 and /2. As it stands now, /2 houses mandrake 8.0. It used
to be my host distro; then lfs got going and it blew up; I just have
enough to get kmail going in it now. Dead handy when an installation
failed. I mount them automatically.
> anyways LC_MESSAGES/SYS_LC_MESSAGES do not belong into share but lib
Rely on Mandrake to totally screw up everything like that. That's what's
so awful about them; nothing works without an rpm, so you never
learn anything. The reason nothing works is that they have buggered it.
> I am tempted to just tar my old nls docs up and send them to you ;)
> Ok, short overview what is what:
> /usr/share/locale/ all this stuff are ready/compiled translations
> /usr/share/i18n/ all this stuff is raw material needed by localedef
> -"-/locale-->s<--- (the only one ending with s) country raw material
> -"-/charmaps charater set raw material
> /usr/lib/locale/ all this stuff are ready/compiled locale archives
> First line is uninteresting for us. Translation is independent from
> localization (flatly spoken), so forget /usr/share/locale completely,
> forget all directories containing .mo files, too. Not our deal now.
> The next ones are our candidates. I tell you what `localedef ...` does:
> localedef compile a locale archive
> -i en_GB from /usr/share/i18n/locales/en_GB raw country file
> -f ISO-8859-1 and /usr/share/i18n/charmaps/ISO-8859-1(.gz) raw charset
> en_GB and put the result into /usr/lib/locale/en_GB directory
Let's test that particular nugget of wisdom (and localedef)
/goes away. Becomes root, and farts with localedef
> Imagine localedef being equal to gcc.
> gcc compiles from raw <src>/pack/lib/files
> and raw <src>/pack/prog/files
> a binary <src>/pack/prog/bin
> localedef compiles from raw /usr/share/i18n/locales/file
> and raw /usr/share/i18n/charmaps/files
> some archives /usr/lib/locale/dir/files
> In both cases the sources are sharable, they can be used with any
> compiler which can handle the sources. And in both cases the final
> location of the ready/compiled result is important to work. A binary
> program would like to be in your PATH to be called directly; and the
> locale archives want to be in /usr/lib/locale (because they are not
> sharable but dependend on the systems glibc which has to work with it).
The results, naturally, were failure :-(. What I tried was
localedef -i en_GB -f iso8859-1 en_GB - which barfed on a number of
points. I also tried
localedef -i en_IE at euro -f iso8859-15 en_IE at euro
And this one barfed on only one
localedef -i en_IE at euro -f iso8859-1 en_IE at euro
en_IE at euro:53: LC_MONETARY: unknown character in field `currency_symbol'
no output file produced because warning were issued
This is the offending line.
(Hopefully that's a euro sign)
I did try unsetting all bogus locales (I
have no real ones to set). Eventually I used the -c option to force
output. I don't know what it's bellyaching about - I have the three
currency symbols I need
I eventually noted the -c (= force output) and used it for en_GB and
en_IE'euro, going on the presumption that anything is better than
nothing. NOW look.
LANGUAGE LC_COLLATE LC_MEASUREMENT LC_NAME LC_TELEPHONE
LC_ADDRESS LC_CTYPE LC_MESSAGES LC_NUMERIC LC_TIME
LC_ALL LC_IDENTIFICATION LC_MONETARY LC_PAPER LC_TYPE
I even crashed a perl script or three that I had lying around and my
strange perl warning was gone. I took care to use a console that had
locales set, as one of them hasn't right now. So it appears I had 2
1. root hadn't run localedef, largely because the lfs 3.3 book
never suggested it.
2. The Peter Principle applies: "Everyone is promoted to the
level at which he is incompetent!" In this case, it was me, being
promoted to root ;-).
> No, blindly overinstalling will not help us.
> Your orignally installed raw material looks ok from the diff output,
> so we can use those (from your /usr/share/i18n/ dir). Make sure the
> share/i18n dirs have at least r-xr-xr-x (w not required now) and the
> files in it have at least r--r--r-- (r is enough) - one never knows.
> The only thing which is additionally involved now is the localedef
> program - and you just built a new one, so we will use the new one
> for testing (and only if that one does things right, we can go on).
That was an idea I hadn't had
/goes off and tries running the new localedef in ~/glibc-build
This produces the same error. I consequently presume the test below is a
> You can do this as normal user:
> # we want an own test dir instead of /usr/lib/locale
> mkdir -p $HOME/mylocaletest
> # just to make sure we did not get any umasking in the way
> chmod 755 $HOME/mylocaletest
> # here is our new binary, I assume /usr/src from your build commands
> cd /usr/src/glibc-build/locale/
> # make sure permissions are correct (should list localedef)
> ls -l localedef | grep 'rwxr-xr-x'
> # use the binary here to compile en_GB and put results into test dir
> ./localedef -i en_GB -f ISO-8859-1 $HOME/mylocaletest/en_GB
> # verify the created archive is correct
> ls -R $HOME/mylocaletest/en_GB
> output should look something alike
> Hoping this brings us a bit further near solving.
Thanks very much Erika - that stuff is a nightmare! Withoiut your
patient halp this would not have been cracked. What a complicated
and ... ... strange (not wishing to start a flame war) way to go about
doing any task.
With best Regards,
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support