coreutils uname-2 patch

Jeremy Utley jeremy at
Sat Oct 30 16:59:10 PDT 2004

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


More information about the hlfs-dev mailing list