On Friday 28 November 2008 10:31:44 pm Ken Moffat wrote: > On Fri, Nov 28, 2008 at 08:34:51PM +0000, b-vol wrote: > > On Friday 28 November 2008 08:16:56 pm Ken Moffat wrote: > > > If your uk.map.gz matches mine, perhaps kbd cannot handle the > > > gzipped file for some reason. > > > > gz on on the uk.map.gz file I copied to root seems to work:-see below > > I think you misunderstood - what you've shown merely shows that gzip > can make a good job of decompressing it. That does show that you > have compiled gzip. > > I was assuming that kbd links dynamically to zlib, but that seems > not to be the case on my current system. [ looks at the code ]. > OK, the relevant place is in findfile.c where it uses "gzip -d -c" > for .gz files (it calls this if the file has a .gz extension). And > we can probably assume that gzip -d -c [ zcat ] works. > > Have you tried loading the decompressed file (uk.map in /root) by > using 'loadkeys /root/uk.map' (specifying the pathname might be > important). > > If that doesn't work, I think the problem is a generic failure, and > the error message might not be related to the cause, i.e. the code > mt an error the programmer hadn't expected. > > If using loadkeys with the path to the uncompressed file did work, > try using it with the path to the compressed file. Hmm, I think you > tried that already ? I'm starting to believe you have a more > general problem. > > Consider if you have done anything different from what the book says > (apart from a slightly newer kernel, newer binutils, different udev - > none of those sound likely to cause this apparent miscompilation). > e.g. optimizations in your CFLAGS. > > Try building strace. Then run something like > strace loadkeys uk.map.gz 2>trace > and review the (perhaps copious) output in the trace file, looking > for error messages and also to see where it is looking for the map > file. BTW don't post the file to the list. > > Look for - > > o missing files that probably should exist - processor-specific glibc > files can be ignored) > > o perhaps a missing device > > o strange paths for where it is looking - or just not in the correct > /lib/keymaps directory - you had that as 'keymap' in what you > posted, but I assume that was an error in copying it by hand > > After that, I'm afraid I'm out of ideas. > > As to your other two packages which failed to compile, I know > nothing about them. If you have a graphical browser you can search > from http://oss-security.openwall.org/wiki/distro-patches - > certainly, fedora has linux-atm - in fact, this link will hopefully > fix that one, after you sort out loadkeys: > > http://cvs.fedoraproject.org/viewvc/rpms/linux-atm/F-10/linux-atm-gcc43.pat >ch?revision=1.1 (that's from finding the package name in the link from > oss-security, going to F-10 (the latest), selecting the patch, and using > *download* to avoid getting html entities in it. > > ĸen
this is what loadkeys uk.map and loadkeys /root/up.map gives bash-3.2# ls /root/uk.map /root/uk.map bash-3.2# loadkeys uk.map Loading uk.map uk.map:1: syntax error syntax error in map file key bindings not changed bash-3.2# ls /root/uk.map /root/uk.map bash-3.2# loadkeys /root/uk.map Loading /root/uk.map /root/uk.map:1: syntax error syntax error in map file key bindings not changed bash-3.2# I am going to have a go using strace and will report the findings. thanks for the suggestions b-vol -- ################################### “Common sense teaches that booksellers should not speculate in hops, or bankers in turpentine; that railways should not be promoted by maiden ladies, or canals by beneficed clergymen ....” Walter Bagehot-economist: 1826-1877 _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
