What do I recompile?

Declan. Moriarty declan.moriarty at ntlworld.ie
Fri Jul 11 02:21:21 PDT 2003


On Thu, Jul 10, 2003 at 12:08:37AM +0200, Erika Pacholleck enlightened
us thusly
> [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?  

No. I still have the original tar.gz files I built as tar.gz files on a
home brewed cdrom full of tar.gz and tar.bz2 files. 

> I don't dare to think that /usr/lib/gconv is incomplete 
[snip]
Listen Erika - there isn't going to be a rupture of the continuity of 
space, or time. At the very worst, one crappy old pc will fall over in
one of it's three operating systems ;-)
 
> > 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.
[snip]
Let's be frank - the results couldn't be worse, could they? :-/
> 
> > 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
>                              ^^^^^^^^^
That may have been tried(iso8859-1). First and forced attempts were with
iso8859-15 for en_IE at euro, and iso8859-1 for en_GB

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

It appears I 'touched' them at an earlier date to see if that would shut
up those annoying errors. They were zero length files with an earlier 
date.In the en_GB dir only. They're not there now. Root passed through.
;genius: /usr/lib/locale$ ls -l en_IE at euro
total 232
-rw-r--r--    2 root     root          136 Jul  9 13:17 LC_ADDRESS
-rw-r--r--    2 root     root        15899 Jul  9 13:17 LC_COLLATE
-rw-r--r--    2 root     root       172916 Jul  9 13:17 LC_CTYPE
-rw-r--r--    1 root     root          443 Jul  9 13:17
LC_IDENTIFICATION
-rw-r--r--    2 root     root           32 Jul  9 13:17 LC_MEASUREMENT
drwxr-xr-x    2 root     root         4096 Jul  9 13:17 LC_MESSAGES/
-rw-r--r--    1 root     root          291 Jul  9 13:17 LC_MONETARY
-rw-r--r--    2 root     root           71 Jul  9 13:17 LC_NAME
-rw-r--r--    2 root     root           63 Jul  9 13:17 LC_NUMERIC
-rw-r--r--    2 root     root           43 Jul  9 13:17 LC_PAPER
-rw-r--r--    1 root     root           59 Jul  9 13:17 LC_TELEPHONE
-rw-r--r--    2 root     root         2384 Jul  9 13:17 LC_TIME
;genius: /usr/lib/locale$ ls -l en_GB
total 232
-rw-r--r--    2 root     root          136 Jul  9 13:17 LC_ADDRESS
-rw-r--r--    2 root     root        15899 Jul  9 13:17 LC_COLLATE
-rw-r--r--    2 root     root       172916 Jul  9 13:17 LC_CTYPE
-rw-r--r--    1 root     root          315 Jul  9 13:18
LC_IDENTIFICATION
-rw-r--r--    2 root     root           32 Jul  9 13:17 LC_MEASUREMENT
-rw-r--r--    1 root     root           61 Jul  9 13:18 LC_MESSAGES
-rw-r--r--    1 root     root          291 Jul  9 13:18 LC_MONETARY
-rw-r--r--    2 root     root           71 Jul  9 13:17 LC_NAME
-rw-r--r--    2 root     root           63 Jul  9 13:17 LC_NUMERIC
-rw-r--r--    2 root     root           43 Jul  9 13:17 LC_PAPER
-rw-r--r--    1 root     root           65 Jul  9 13:18 LC_TELEPHONE
-rw-r--r--    2 root     root         2384 Jul  9 13:17 LC_TIME

Does that validate things any? Just looking, I'd better switch to
en_IE at euro. I don't like LC_MESSAGES being a file in one lot and a
directory in the other.
> 
> > 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
[snip]

> I guess, it had the "make localedata/install-locales" line which is

The glibc build instructions in the 3.3 book?
> 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). 

Yes, and my glibc build obviously bombed and I didn't notice it. Or more
likely I pretended I didn't notice it. Which means it's unlikely to be
perfect anyhow.
> 
> > /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.

I will do it the proper way as user soon, and report back. I took the
view that there's plenty of locales out there. I could afford to muck up
half the world's locales ;-). Things like de_DE that I'd hardly be
likely to use :-)); Mind you, Seriously, I might well end up with it - 
it's one of the more versatile locales.
the more versatile
> 
> # 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

No - I'll try the user commands. Something like this would only go
wrong if I tried it
make install_root=/tmp/glibc-new install

Those things NEVER work for me. Sod's Law. When you're juggling knives,
you learn to hold the handles ;-).
> 
> > - that stuff is a nightmare!
>   You have not yet been hacking own stuff with 2.3.2
I did have the 2.3.36 kernel which broke pppd, and swallowed gigabytes
of memory down some huge hole in between it and X.

> > ... (not wishing to start a flame war) ...
>   what a pity, just got out my matches to make a nice - fire!  --
 

-- 

	With best Regards,


	Declan Moriarty.
-- 
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