coreutils uname-2 patch
robert at linuxfromscratch.org
Sat Oct 30 12:30:13 PDT 2004
On October 30, 2004 12:45 pm, Jeremy Utley wrote:
> Robert Connolly wrote:
> >This might belong on bugzilla...
> >In chapter 6 when compiling coreutils-5.2.1 with
> > coreutils-5.2.1-uname-2.patch with -fPIC I get this:
> >uname.c: In function `main':
> >uname.c:364: warning: initialization discards qualifiers from pointer
> > target type
> >uname.c: In function `has_sse':
> >uname.c:416: error: can't find a register in class `BREG' while reloading
> >make: *** [uname.o] Error 1
> >'has_sse' is a new function added by the uname-2 patch. The uname-1 patch
> > in LFS-5.1.1 compiles fine. The uname-1 patch was originally from
> > coreutils-5.0, the uname-2 patch is new from Zack Winkles. You should be
> > able to reproduce this with CFLAGS="-fPIC", I was using -fPIC out of gcc
> > specs.
> >Perhaps lfs-hackers people could comment if this would be a factor in
> > using uname-1 in unstable in the future?
> uname-1 gives incorrect output, which is the reason for uname-2 in the
> first place...to get correct output from uname so programs do not
> miscompile. Why are you passing CFLAGS to coreutils - without this, it
> compiles and works just fine.
I'm passing -fPIC on everything to take advantage of Grsec kernel features.
The code in uname-2 is not pic, and there doesn't seem to be anything I can
do about it. I tried doing if !defined(__pic__) before has_sse() but I just
got errors in other places for the same reasons.
There are a lot of these patches around. I've attached an alternate. HLFS
can't use the uname-2 patch because of its asm code, LFS may prefer it
because of its functionality, but it looks like HLFS will use this attached
uname-2 gives me:
i686 athlon i386 GNU/Linux
This uname-3 gives me:
i686 AMD Duron(tm) Processor AuthenticAMD GNU/Linux
uname-3 is more accurate for my system, no idea about others. If I remember
correctly there is a problem with using /proc/cpuinfo vendor_id and model
name with some architectures, but I'm not sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3789 bytes
Desc: not available
More information about the hlfs-dev