coreutils uname-2 patch

Robert Connolly robert at linuxfromscratch.org
Sat Oct 30 21:04:14 PDT 2004


On October 30, 2004 07:59 pm, Jeremy Utley wrote:
> On Sat, October 30, 2004 12:30 pm, Robert Connolly said:
> > 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.
>
> No, uname-3 is NOT more accurate.  the second field should be the value
> that would be passed to -march for proper operation of the uname command.
> This will cause subtle optimization problems for a number of programs, GMP
> being one that stands out.
>
> -J-

Okay, thank you.



More information about the hlfs-dev mailing list