RH7.3 can't compile 2.6.0-test8

RH7.3 can't compile 2.6.0-test8

[Norman Diamond]

I understand that Red Hat's GCC is nonstandard, but this still surprised me.
In the "make" output below, the word エラー means error.


fs/proc/array.c: In function `proc_pid_stat':
fs/proc/array.c:398: Unrecognizable insn:
(insn/i 1332 1672 1666 (parallel[
            (set (reg:SI 0 eax)
                (asm_operands ("") ("=a") 0[
                        (reg:DI 1 edx)
                    ]
                    [
                        (asm_input:DI ("A"))
                    ]  ("include/linux/times.h") 37))
            (set (reg:SI 1 edx)
                (asm_operands ("") ("=d") 1[
                        (reg:DI 1 edx)
                    ]
                    [
                        (asm_input:DI ("A"))
                    ]  ("include/linux/times.h") 37))
            (clobber (reg:QI 19 dirflag))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ] ) -1 (insn_list 1326 (nil))
    (nil))
fs/proc/array.c:398: confused by earlier errors, bailing out
make[2]: *** [fs/proc/array.o] エラー 1
make[1]: *** [fs/proc] エラー 2
make: *** [fs] エラー 2
[ndiamond@c1pc40 linux-2.6.0-test8]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
[ndiamond@c1pc40 linux-2.6.0-test8]$ rpm -qa binutils
binutils-2.11.93.0.2-11

Re: RH7.3 can't compile 2.6.0-test8

[Christian Kujau]

Norman Diamond schrieb:
[...]
> fs/proc/array.c:398: confused by earlier errors, bailing out
> make[2]: *** [fs/proc/array.o] エラー 1
> make[1]: *** [fs/proc] エラー 2
> make: *** [fs] エラー 2
> [ndiamond@c1pc40 linux-2.6.0-test8]$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
> [ndiamond@c1pc40 linux-2.6.0-test8]$ rpm -qa binutils
> binutils-2.11.93.0.2-11

did you try with a gcc 3.x too? perhaps it's (only) a compiler issue...

Christian.
-- 
BOFH excuse #285:

Telecommunications is upgrading.

Re: RH7.3 can't compile 2.6.0-test8

[Marco Roeland]

On Monday October 20th 2003 at 16:01 Christian Kujau wrote:

> Norman Diamond schrieb:
> [...]
> > [ndiamond@c1pc40 linux-2.6.0-test8]$ gcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> > gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
> > [ndiamond@c1pc40 linux-2.6.0-test8]$ rpm -qa binutils
> > binutils-2.11.93.0.2-11
> 
> did you try with a gcc 3.x too? perhaps it's (only) a compiler issue...

No, you just need to upgrade binutils to version 2.12 or higher, as mentioned
in Documentation/Changes. The gcc version is fine.
-- 
Marco Roeland

Re: RH7.3 can't compile 2.6.0-test8

[Paul Larson]

On Mon, 2003-10-20 at 11:43, Marco Roeland wrote:
> No, you just need to upgrade binutils to version 2.12 or higher, as mentioned
> in Documentation/Changes. The gcc version is fine.
Apparently that's not quite enough.  I have a machine on binutils
2.12.90.0.9 and I'm still getting the same failure.

-Paul Larson

Re: RH7.3 can't compile 2.6.0-test8

[Norman Diamond]

Marco Roeland wrote:
> On Monday October 20th 2003 at 16:01 Christian Kujau wrote:
> > Norman Diamond schrieb:
> > [...]
> > > [ndiamond@c1pc40 linux-2.6.0-test8]$ gcc -v
> > > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> > > gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
> > > [ndiamond@c1pc40 linux-2.6.0-test8]$ rpm -qa binutils
> > > binutils-2.11.93.0.2-11
> >
> > did you try with a gcc 3.x too? perhaps it's (only) a compiler issue...
>
> No, you just need to upgrade binutils to version 2.12 or higher, as
> mentioned in Documentation/Changes. The gcc version is fine.

I disagree with both of you.

I downloaded binutils, I think 2.14.96.0 or thereabouts (I'm away from the
machine now).  It rejected rpm -U because it depends on a version of
glibc-devel which is newer than RH 7.3's version of glibc-devel.  I didn't
examine yet whether it is possible to upgrade glibc-devel without upgrading
gcc, and didn't download any version of those yet in order to try binutils
again.

The Readme for 2.6.0-test6 still said that gcc 2.95 is required (I confess
to not reading Readme for test8 yet.)   I reported a compilation problem in
test6 using gcc 3.2.something in SuSE on a different machine, and it seems
believable that gcc 2.95 is still required.  As mentioned at the beginning
of this thread, I understand that Red Hat's gcc 2.96 is nonstandard.  If I
make any changes to binutils and glibc-devel and gcc, surely it should be to
install gcc 2.95 and related packages which would be compatible with that
version.  It should not be to install gcc 3.anything, or glibc-devel or
binutils that depend on it.

Re: RH7.3 can't compile 2.6.0-test8

[rwhron]

> The Readme for 2.6.0-test6 still said that gcc 2.95 is required

test8 Changes still says gcc-2.95.3.  I saw the same compile error
on RedHat 7.2.  I ended up using gcc-3.3.1.  Later I saw this patch:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106651554401143&w=2

It's supposed to fix test8 compile with gcc-2.96 for RedHat 7.x.

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html

Re: RH7.3 can't compile 2.6.0-test8

[Marco Roeland]

Op dinsdag 21 oktober 2003 om 09:19 uur schreef rwhron@earthlink.net het volgende:

> > The Readme for 2.6.0-test6 still said that gcc 2.95 is required
> 
> test8 Changes still says gcc-2.95.3.  I saw the same compile error
> on RedHat 7.2.  I ended up using gcc-3.3.1.  Later I saw this patch:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106651554401143&w=2
> 
> It's supposed to fix test8 compile with gcc-2.96 for RedHat 7.x.

It seems an odd fix though, the variable tty_nr is at most set once
inside the function, and is inaccessible to other functions so why it
should be volatile seems unclear to me. It might solve the compilation
(now that I look again the original error messages mention gcc internal
representation, so the suggestion of binutils at fault seems unwarranted)
but that seems by accident, not by design?

Perhaps if the huge sprintf with 40+ arguments (fs/proc/array.c, line 346)
amongst which several trinary operators, were to be split up into several
parts, might that not solve the problem more elegantly?
-- 
Marco Roeland