What do I recompile?

Erika Pacholleck pchllck at nexgo.de
Wed Jul 9 15:08:37 PDT 2003

[09.07.2003] Declan. Moriarty <-- :
> On Tue, Jul 08, 2003 at 10:03:32PM +0200, Erika Pacholleck enlightened us thusly
> OK. I have used the original tarball (Stored on a cdrom). Maybe I should
> get suspicious of that? 

Does that mean, you tared your first lfs build up, put it onto a CD and
untarred it to your disk again - and now we discover the first one was
not built ok?
I don't dare to think that /usr/lib/gconv is incomplete (there is a file
in that dir called gconf-modules and the 4th column (alias=1st column)
tells you the base name of the file that should be present as .so file.
If it is only the glibc-{linuxthreads-}2.2.5.tar.gz sources from CD,
that one would bomb out building if it were not ok.

> > The next ones are our candidates. I tell you what `localedef ...` does:
> > [snip]
> Let's test that particular nugget of wisdom (and localedef)
> /goes away. Becomes root, and farts with localedef

Ohoh, that was an explanation and not meant as, become root and try out
everything as root immediately.

> 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

We knew already it failed, I mean that was the reason why we started
looking at each involved component for this command (are the raw files
in /usr/share/i18n ok, is the localedef binary ok?).

> 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. 
> currency_symbol         "<U20AC>"
> (Hopefully that's a euro sign)

It is, U means unicode notation, 20AC describes the "picture" in the
font to "paint" onto your screen.
Another one: ISO-8859-1 does not know the Euro character. If you want
the Euro you need ISO-8859-15.
And another one: the "-f some_charset" references the filename (without
the .gz) in /usr/share/i18n/charsets and those are written ISO-8859-1
or -15 and I am not sure what happens if you write the charset name
just in whatever way you like.

> I did try unsetting all bogus locales (I have no real ones to set).

The original starting situation is:
1. LANG="POSIX"        |
2. all LC_XX="POSIX"   |- type `locale` to check what they are
3. LC_ALL=             |
-. LANGUAGE=""          - `echo $LANGUAGE` to check
And ideally root knows enough english not to change anything of this.
But no matter whether a user with or without any locale settings is
calling localedef, it works (so those settings do not influence the

> 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 
> 	1. £
> 	2. €
> 	3. $
> 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.
> ls /usr/lib/locale/en_GB

There is nothing wrong with -c if you later verify all is correct. BUT
LANGUAGE does not belong here, it is an environment variable.
LC_ALL does not belong here, it is no own category but (flatly said)
internally used as a summary to catch all LC_XX variables.
Sorry I have again to say, this one is not correct.
I wonder how these are getting into it.

> 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
> problems
> 	1. root hadn't run localedef, largely because the lfs 3.3 book
> never suggested it.

I guess, it had the "make localedata/install-locales" line which is
creating every possible locale (and clutters up your /usr/lib/locale
directory with lots of never used stuff while occupying your system
for some more hours). 

> /goes off and tries running the new localedef in ~/glibc-build
> This produces the same error. I consequently presume the test below is a
> little unnecessary?
> > 
> > You can do this as normal user:
> > [snip commands]

Well, I wanted to make sure, that we do not mess up the system dirs with
some root commands but separate it. And as a normal LFS has localedef
world executable, you can do this as normal user (and not as root) and
separate the result into some users newly created testdir.

So, if you did not yet just trash that whole <whatever you like>, I
suggest you try those user commands. If the the results in mylocaletest
turn out to look the same as your list above from /usr/lib/locale/en_GB
there is only one idea left I have (except just do a complete new
system from scratch):
install the newly build glibc into a test dir and compare the contents
of that file by file with the contents of your system, so you see where
the glibc part differs.

# create a test directory for the new glibc install
  mkdir -p /tmp/glibc-new
# we go on with the new glibc building and install into the test dir
  cd ~/glibc-build
# this is installing the normal glibc stuff into the test dir
  make install_root=/tmp/glibc-new install
# this is the creation of all locales into the test dir
# if you want to reduce the locales you can first delete lines in
# glibc-2.2.5/localedata/SUPPORTED, specially zh_ are time consumers
  make install_root=/tmp/glibc-new localedata/install-locales

> - that stuff is a nightmare!
  You have not yet been hacking own stuff with 2.3.2
> ... (not wishing to start a flame war) ...
  what a pity, just got out my matches to make a nice - fire!
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