What do I recompile?

Erika Pacholleck pchllck at nexgo.de
Tue Jul 8 13:03:32 PDT 2003


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.

> I do have /usr/share/locale/en_GB/LC_MESSAGES but no copies of
> SYS_LC_MESSAGES or LC_TIME, but only some .mo files which I presume
> are different.

Slowly with the young horses!
You look in /usr/--->share/locale<--- now and
this one is for translations, so .mo files are absolutely correct.

> This is all a bit beyond me - why have pretty much the same guff in
> /usr/share/locale, /usr/lib/locale, /usr/local/share/locale,
> usr/local/lib/locale and /usr/share/i18n/locales?

I looked through your attachment. A general advice: look what the
directory contains, if it contains .mo files, then it is for
translations and not localizations: see, from your attach all these
------------
/usr/share/locale/ca/LC_MESSAGES/libc.mo ...
/usr/src/j2re1.4.1_01/lib/locale/de/LC_MESSAGES/sunw_java_plugin.mo ...
/usr/local/lib/locale/de/LC_MESSAGES/sunw_java_plugin.mo ...
/2/usr/share/vim/lang/af/LC_MESSAGES/vim.mo ...
------------ are translating english messages into ca/de/af languages
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?)
/2/usr/share/locale/CP1251/LC_MESSAGES
/2/usr/share/locale/CP1251/LC_MESSAGES/SYS_LC_MESSAGES
anyways LC_MESSAGES/SYS_LC_MESSAGES do not belong into share but lib

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

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).

> My box is looking like windows:
> slocate LC_MESSAGES > locale_stuff 2>&1
  Hehe, my box does not even look like linux:
  slocate: noch so'n Scherz und ich lache
  (another joke like this and I start laughing; a private de .mo)
> LC_MESSAGES isn't even in the glibc source, as you can see.
  Correct, LC_MESSAGES is the result of a `localedef ...` command.
> How do I find out which directories the system is looking at?
  For what command? ... no, don't say slocate now or I shoot you ...
> What's happened to my LC_MESSAGES?
  Which ones in which directory?
> Are they in some other package I'm going to find out about?
  No, not for your LFS system ... distros should install them by default
> I only have glibc-2.2.5 & glibc-linuxthreads
  That will do, as said this directory is the product/result of
  localedef doing its task.
> I did a search for SYS_LC_MESSAGES, and only found it on my legacy
> Mandrake 8.0 system with glibc-2.2.2.
  That's correct, a distro should install them and it did.
> There is none in the glibc source, or the build directory.
> They have locale files in a locales rpm, in fileutils, in xmms, and
> about 10 other packages of the tiny system I have installed there, so
> I presume they scatter them like confetti.
  .mo files - but you know already how to forget, don't you?

> I rooted out the lfs-3.3 book, and did the following as per instructions:
> Unpack glibc-linuxthreads-2.2.5 in /usr/src/glibc-2.2.5
> Unset all locales and CFLAGS, & CXXFLAGS
> 
> touch /etc/ld.so.conf &&
> cp malloc/Makefile malloc/Makefile.backup &&
> sed 's%\$(PERL)%/usr/bin/perl%' malloc/Makefile.backup >
>   malloc/Makefile &&
> cp login/Makefile login/Makefile.backup &&
> sed 's/root/0/' login/Makefile.backup > login/Makefile &&
> mkdir ../glibc-build &&
> cd ../glibc-build &&
> ../glibc-2.2.5/configure --prefix=/usr \
>   --enable-add-ons --libexecdir=/usr/bin &&
> echo "cross-compiling = no" > configparms &&
> make
> 
> After a few initial stupidities it built without error. 

> root:/usr/src/glibc-2.2.5#diff localedata/locales/en_GB \
> /usr/share/i18n/locales/en_GB   showed no differences.
> 
> I am remarkably shy of doing a 'make install' on glibc. I read somewhere
> (mebbe the INSTALL in glibc) about having to present glibc with a virgin
> /usr/include directory. 
> There is also a 'make localedata/install-locales' target used in the
> book. Is that a safer bet ?(BTW, I bet it changes nothing)

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).

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
/home/albert/mylocaletest/en_GB/:
LC_ADDRESS
LC_COLLATE
LC_CTYPE
LC_IDENTIFICATION
LC_MEASUREMENT
LC_MESSAGES
LC_MONETARY
LC_NAME
LC_NUMERIC
LC_PAPER
LC_TELEPHONE
LC_TIME
/home/albert/mylocaletest/en_GB/LC_MESSAGES:
SYS_LC_MESSAGES

Hoping this brings us a bit further near solving.
-- 
Erika ...---...: pacholleck at nexgo dot de
-- 
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 mailing list