coreutils uname-2 patch

Robert Connolly 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
> >`asm'
> >make[3]: *** [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?
> >
> >Robert
>
> 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.
>
> -J-

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 
one instead.

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.

Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coreutils-5.2.1-uname-3.patch
Type: text/x-diff
Size: 3789 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20041030/212c794e/attachment.patch>


More information about the hlfs-dev mailing list