Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jakub Jelinek]

On Mon, Oct 23, 2000 at 12:06:31PM +, David Wragg wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> writes:
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
> 
> As in the RedHat 2.96?  Try compiling the following on RedHat 7.0 x86
> with "gcc -O2" and take a look at the generated code.  Nice, isn't it?
> 
> 
> #include 
> 
> void foo(void)
> {
> struct itimerval iv;
> 
> iv.it_interval.tv_sec = 0;
> iv.it_interval.tv_usec = 25;
> iv.it_value = iv.it_interval;
> 
> setitimer(ITIMER_REAL, , NULL);
> }

Yes, this is a bug in the compiler (which I hope to fix today, CVS gcc is
broken as well), though the actual place which causes this to be miscompiled
is in the system headers where a restrict keyword is used on an incomplete
struct timeval forward definitions pointer and due to bug is set in the type
structure itself (at least that's my guess, need to run it under debugger
today - but if the select prototype is moved after the full struct timeval
definition, everything works correctly). Note that gcc 2.95.2 has some
restrict keyword related bugs as well (which glibc had to work around in
the headers; the bug was in 2.95.x only), it is not just 2.96.

Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jakub Jelinek]

On Mon, Oct 23, 2000 at 12:06:31PM +, David Wragg wrote:
 Gregory Maxwell [EMAIL PROTECTED] writes:
  If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
 
 As in the RedHat 2.96?  Try compiling the following on RedHat 7.0 x86
 with "gcc -O2" and take a look at the generated code.  Nice, isn't it?
 
 
 #include sys/time.h
 
 void foo(void)
 {
 struct itimerval iv;
 
 iv.it_interval.tv_sec = 0;
 iv.it_interval.tv_usec = 25;
 iv.it_value = iv.it_interval;
 
 setitimer(ITIMER_REAL, iv, NULL);
 }

Yes, this is a bug in the compiler (which I hope to fix today, CVS gcc is
broken as well), though the actual place which causes this to be miscompiled
is in the system headers where a restrict keyword is used on an incomplete
struct timeval forward definitions pointer and due to bug is set in the type
structure itself (at least that's my guess, need to run it under debugger
today - but if the select prototype is moved after the full struct timeval
definition, everything works correctly). Note that gcc 2.95.2 has some
restrict keyword related bugs as well (which glibc had to work around in
the headers; the bug was in 2.95.x only), it is not just 2.96.

Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Michael Meissner]

On Mon, Oct 23, 2000 at 07:48:08PM -0400, David Relson wrote:
> Horst,
> 
> What you say is correct.  Early comments on gcc-2.96 reflected preprocessor 
> changes which made it impossible to compile a kernel.  Later comments, 
> particularly David Wragg's "struct itimerval" example, show that compiler 
> optimizations is broken.
> 
> My recollection is that the behavior of "a[i] = b[i++]" is well defined, 
> i.e. in the standard.  However it's been years since I paid attention to 
> those details, so I may be wrong.

Umm, no, since

 a[i] = b[i++]

does not have a sequence, it is explicitly undefined behavior in the standard.
As I recall Bernd Schmidt recently found a number of places where the above
construct is used in the Linux kernel.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

At 05:44 AM 10/23/00, Horst von Brand wrote:
>David Relson <[EMAIL PROTECTED]> said:
>
>Not just a preprocessor change.
>...
>This is true for a correct compiler (ever seen a correct piece of
>software?)  compiling strictly standard-conforming source. The kernel is
>_not_ standard-conforming, and many places are writen just like they are to
>trick the compiler into generating particular code, some places assume that
>undefined behaviour (i.e., a[i] = b[i++] and such) works in a certain way,
>that the compiler pads structures in a certain way, ...
>...
>Yes. The existing program is wrong in that it woprked by chance, not
>because it was written right.


Horst,

What you say is correct.  Early comments on gcc-2.96 reflected preprocessor 
changes which made it impossible to compile a kernel.  Later comments, 
particularly David Wragg's "struct itimerval" example, show that compiler 
optimizations is broken.

My recollection is that the behavior of "a[i] = b[i++]" is well defined, 
i.e. in the standard.  However it's been years since I paid attention to 
those details, so I may be wrong.

Anyhow, as we all know, gcc-2.96 is not ready for prime time.

David


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

David Relson <[EMAIL PROTECTED]> said:
> At 09:14 PM 10/22/00, Horst von Brand wrote:
> >Jurgen Kramer <[EMAIL PROTECTED]> said:
> > > You can blame it on the compiler which is included with RH7.0. It's a
> > > pre-release version of some sort. It seems that the gcc people are not
> > > happy that RH included this version with RH7.

> >It is the *kernel's* fault, as far as can be ascertained now. The compiler
> >is stricter, and implements new optimizations, for which the kernel (being
> >only ever compiled with gcc) is just unprepared.

> The problem, as I understand it, is that gcc-2.96 handles language 
> constructs slightly different than older compilers.  This is a preprocessor 
> change, not an optimization problem.

Not just a preprocessor change.

> To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
> worked with compilers (some years ago), I always took it as an article of 
> faith that the same answer(s) would be generated whether optimization was 
> turned on or not.

This is true for a correct compiler (ever seen a correct piece of
software?)  compiling strictly standard-conforming source. The kernel is
_not_ standard-conforming, and many places are writen just like they are to
trick the compiler into generating particular code, some places assume that
undefined behaviour (i.e., a[i] = b[i++] and such) works in a certain way,
that the compiler pads structures in a certain way, ...

>   Optimization should always be a way to do a task either 
> quicker (fewer instructions executing, less executing time, etc) or shorter 
> (less memory needed for the instructions).  Optimization should never, 
> never give a different result.  Having new optimizations break an executing 
> program is simply wrong.

Yes. The existing program is wrong in that it woprked by chance, not
because it was written right.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Andrea Arcangeli]

On Mon, Oct 23, 2000 at 12:05:22PM -0400, Aaron Sethman wrote:
> [..] gcc is doing the right thing, just not what you expected.

This code:

iv.it_interval.tv_sec = 0;
iv.it_interval.tv_usec = 25;

iv.it_value = iv.it_interval;

got miscompiled as:

iv.it_value = iv.it_interval; /* read random */

iv.it_interval.tv_sec = 0;
iv.it_interval.tv_usec = 25;

That is an obvious compiler bug. None legal optimization can allow the compiler
to do such reordering (not even with strict aliasing enabled).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Wragg]

Aaron Sethman <[EMAIL PROTECTED]> writes:
> Try compiling the said code with -fno-strict-aliasing, and your problems
> will be solved.

Yes, but I don't think I should have to give gcc flags to get it to
obey the C standard (my example can easily be turned into a
self-contained strictly conforming program, in order to qualify for
the full weight of the standard).

>  gcc is doing the right thing, just not what you expected.

gcc is not doing the right thing.  My example contains no type punning
or other deviations from ISO C which might warrant
-fno-strict-aliasing.  The program should behave as if the assignments
are evaluated sequentially; with this compiler, it does not.

> The kernel already checks to see if gcc can grok -fno-strict-aliasing

Yes, since the kernel needs to say to gcc "I know this code relies on
more than the ISO C semantics, so please be gentle with it".


David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Aaron Sethman]

Try compiling the said code with -fno-strict-aliasing, and your problems
will be solved.  gcc is doing the right thing, just not what you expected.

The kernel already checks to see if gcc can grok -fno-strict-aliasing

Aaron

On 23 Oct 2000, David Wragg wrote:

> Gregory Maxwell <[EMAIL PROTECTED]> writes:
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
> 
> As in the RedHat 2.96?  Try compiling the following on RedHat 7.0 x86
> with "gcc -O2" and take a look at the generated code.  Nice, isn't it?
> 
> 
> #include 
> 
> void foo(void)
> {
> struct itimerval iv;
> 
> iv.it_interval.tv_sec = 0;
> iv.it_interval.tv_usec = 25;
> iv.it_value = iv.it_interval;
> 
> setitimer(ITIMER_REAL, , NULL);
> }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Wragg]

Gregory Maxwell <[EMAIL PROTECTED]> writes:
> If 2.96 is broken, I'd appreciate it if you would describe the breakage. 

As in the RedHat 2.96?  Try compiling the following on RedHat 7.0 x86
with "gcc -O2" and take a look at the generated code.  Nice, isn't it?


#include 

void foo(void)
{
struct itimerval iv;

iv.it_interval.tv_sec = 0;
iv.it_interval.tv_usec = 25;
iv.it_value = iv.it_interval;

setitimer(ITIMER_REAL, , NULL);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Wragg]

Gregory Maxwell [EMAIL PROTECTED] writes:
 If 2.96 is broken, I'd appreciate it if you would describe the breakage. 

As in the RedHat 2.96?  Try compiling the following on RedHat 7.0 x86
with "gcc -O2" and take a look at the generated code.  Nice, isn't it?


#include sys/time.h

void foo(void)
{
struct itimerval iv;

iv.it_interval.tv_sec = 0;
iv.it_interval.tv_usec = 25;
iv.it_value = iv.it_interval;

setitimer(ITIMER_REAL, iv, NULL);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Aaron Sethman]

Try compiling the said code with -fno-strict-aliasing, and your problems
will be solved.  gcc is doing the right thing, just not what you expected.

The kernel already checks to see if gcc can grok -fno-strict-aliasing

Aaron

On 23 Oct 2000, David Wragg wrote:

 Gregory Maxwell [EMAIL PROTECTED] writes:
  If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
 
 As in the RedHat 2.96?  Try compiling the following on RedHat 7.0 x86
 with "gcc -O2" and take a look at the generated code.  Nice, isn't it?
 
 
 #include sys/time.h
 
 void foo(void)
 {
 struct itimerval iv;
 
 iv.it_interval.tv_sec = 0;
 iv.it_interval.tv_usec = 25;
 iv.it_value = iv.it_interval;
 
 setitimer(ITIMER_REAL, iv, NULL);
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Wragg]

Aaron Sethman [EMAIL PROTECTED] writes:
 Try compiling the said code with -fno-strict-aliasing, and your problems
 will be solved.

Yes, but I don't think I should have to give gcc flags to get it to
obey the C standard (my example can easily be turned into a
self-contained strictly conforming program, in order to qualify for
the full weight of the standard).

  gcc is doing the right thing, just not what you expected.

gcc is not doing the right thing.  My example contains no type punning
or other deviations from ISO C which might warrant
-fno-strict-aliasing.  The program should behave as if the assignments
are evaluated sequentially; with this compiler, it does not.

 The kernel already checks to see if gcc can grok -fno-strict-aliasing

Yes, since the kernel needs to say to gcc "I know this code relies on
more than the ISO C semantics, so please be gentle with it".


David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Andrea Arcangeli]

On Mon, Oct 23, 2000 at 12:05:22PM -0400, Aaron Sethman wrote:
 [..] gcc is doing the right thing, just not what you expected.

This code:

iv.it_interval.tv_sec = 0;
iv.it_interval.tv_usec = 25;

iv.it_value = iv.it_interval;

got miscompiled as:

iv.it_value = iv.it_interval; /* read random */

iv.it_interval.tv_sec = 0;
iv.it_interval.tv_usec = 25;

That is an obvious compiler bug. None legal optimization can allow the compiler
to do such reordering (not even with strict aliasing enabled).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

David Relson [EMAIL PROTECTED] said:
 At 09:14 PM 10/22/00, Horst von Brand wrote:
 Jurgen Kramer [EMAIL PROTECTED] said:
   You can blame it on the compiler which is included with RH7.0. It's a
   pre-release version of some sort. It seems that the gcc people are not
   happy that RH included this version with RH7.

 It is the *kernel's* fault, as far as can be ascertained now. The compiler
 is stricter, and implements new optimizations, for which the kernel (being
 only ever compiled with gcc) is just unprepared.

 The problem, as I understand it, is that gcc-2.96 handles language 
 constructs slightly different than older compilers.  This is a preprocessor 
 change, not an optimization problem.

Not just a preprocessor change.

 To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
 worked with compilers (some years ago), I always took it as an article of 
 faith that the same answer(s) would be generated whether optimization was 
 turned on or not.

This is true for a correct compiler (ever seen a correct piece of
software?)  compiling strictly standard-conforming source. The kernel is
_not_ standard-conforming, and many places are writen just like they are to
trick the compiler into generating particular code, some places assume that
undefined behaviour (i.e., a[i] = b[i++] and such) works in a certain way,
that the compiler pads structures in a certain way, ...

   Optimization should always be a way to do a task either 
 quicker (fewer instructions executing, less executing time, etc) or shorter 
 (less memory needed for the instructions).  Optimization should never, 
 never give a different result.  Having new optimizations break an executing 
 program is simply wrong.

Yes. The existing program is wrong in that it woprked by chance, not
because it was written right.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

At 05:44 AM 10/23/00, Horst von Brand wrote:
David Relson [EMAIL PROTECTED] said:

Not just a preprocessor change.
...
This is true for a correct compiler (ever seen a correct piece of
software?)  compiling strictly standard-conforming source. The kernel is
_not_ standard-conforming, and many places are writen just like they are to
trick the compiler into generating particular code, some places assume that
undefined behaviour (i.e., a[i] = b[i++] and such) works in a certain way,
that the compiler pads structures in a certain way, ...
...
Yes. The existing program is wrong in that it woprked by chance, not
because it was written right.


Horst,

What you say is correct.  Early comments on gcc-2.96 reflected preprocessor 
changes which made it impossible to compile a kernel.  Later comments, 
particularly David Wragg's "struct itimerval" example, show that compiler 
optimizations is broken.

My recollection is that the behavior of "a[i] = b[i++]" is well defined, 
i.e. in the standard.  However it's been years since I paid attention to 
those details, so I may be wrong.

Anyhow, as we all know, gcc-2.96 is not ready for prime time.

David


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Michael Meissner]

On Mon, Oct 23, 2000 at 07:48:08PM -0400, David Relson wrote:
 Horst,
 
 What you say is correct.  Early comments on gcc-2.96 reflected preprocessor 
 changes which made it impossible to compile a kernel.  Later comments, 
 particularly David Wragg's "struct itimerval" example, show that compiler 
 optimizations is broken.
 
 My recollection is that the behavior of "a[i] = b[i++]" is well defined, 
 i.e. in the standard.  However it's been years since I paid attention to 
 those details, so I may be wrong.

Umm, no, since

 a[i] = b[i++]

does not have a sequence, it is explicitly undefined behavior in the standard.
As I recall Bernd Schmidt recently found a number of places where the above
construct is used in the Linux kernel.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Michael Meissner]

On Sun, Oct 22, 2000 at 11:16:36PM -0400, David Relson wrote:
> At 09:14 PM 10/22/00, Horst von Brand wrote:
> >Jurgen Kramer <[EMAIL PROTECTED]> said:
> >
> > > You can blame it on the compiler which is included with RH7.0. It's a
> > > pre-release version of some sort. It seems that the gcc people are not
> > > happy that RH included this version with RH7.
> >
> >It is the *kernel's* fault, as far as can be ascertained now. The compiler
> >is stricter, and implements new optimizations, for which the kernel (being
> >only ever compiled with gcc) is just unprepared.
> 
> The problem, as I understand it, is that gcc-2.96 handles language 
> constructs slightly different than older compilers.  This is a preprocessor 
> change, not an optimization problem.
> 
> To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
> worked with compilers (some years ago), I always took it as an article of 
> faith that the same answer(s) would be generated whether optimization was 
> turned on or not.  Optimization should always be a way to do a task either 
> quicker (fewer instructions executing, less executing time, etc) or shorter 
> (less memory needed for the instructions).  Optimization should never, 
> never give a different result.  Having new optimizations break an executing 
> program is simply wrong.

Ummm, that should read "Having new optimizations break a correct exeucting
program...".  For example, the following program:

#include 

int main(){
  int i;
  printf ("i = %d\n", i);
  return 0;
}

will necessarily print different values for i, depending on the optimization
level, what was on the stack and in the registers when main started, and
possibly other criteria.  Just because a program is executing, it doesn't mean
it is correct.

Both the kernel and the compiler are large complex pieces of software, and
almost certainly have bugs in them, and over the years, I have certainly found
some of these bugs as I use new versions of each.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

At 09:14 PM 10/22/00, Horst von Brand wrote:
>Jurgen Kramer <[EMAIL PROTECTED]> said:
>
> > You can blame it on the compiler which is included with RH7.0. It's a
> > pre-release version of some sort. It seems that the gcc people are not
> > happy that RH included this version with RH7.
>
>It is the *kernel's* fault, as far as can be ascertained now. The compiler
>is stricter, and implements new optimizations, for which the kernel (being
>only ever compiled with gcc) is just unprepared.

The problem, as I understand it, is that gcc-2.96 handles language 
constructs slightly different than older compilers.  This is a preprocessor 
change, not an optimization problem.

To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
worked with compilers (some years ago), I always took it as an article of 
faith that the same answer(s) would be generated whether optimization was 
turned on or not.  Optimization should always be a way to do a task either 
quicker (fewer instructions executing, less executing time, etc) or shorter 
(less memory needed for the instructions).  Optimization should never, 
never give a different result.  Having new optimizations break an executing 
program is simply wrong.

David


>--
>Horst von Brand [EMAIL PROTECTED]
>Casilla 9G, Vin~a del Mar, Chile   +56 32 672616


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Sun, Oct 22, 2000 at 10:12:06PM -0300, Horst von Brand wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> said: 
> [...]
> > If you are going to upgrade, you should at least consider going to
> > 2.4.0test-flavor-of-week, so that your crashes will at least contribute to
> > Linux development. :)
> 
> Careful there! 2.4.0-test10-pre3 on i686 is the prime suspect in massive
> reorganization of / here (had to reinstall several packages, and lost most
> of root's account configuration), and it also nibbled at /usr/src (it
> screwed up a directory, and I suspect it bit my gcc tree updated daily from
> CVS, for which I have a backup).

Thanks. After four years of participating on this list, I guess I've come to
ignore the occasional devel-kernel-eats-my-filesystem. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

"Brian F. G. Bidulock" <[EMAIL PROTECTED]> said:
> It has come to our attention that some GNU/Linux distributions are
> currently shipping with ``GCC 2.96''.

Please, not again!

Red Hat 7.0's "GCC 2.96" is binary compatible for C with all past and
future versions. It will probably not be binary compatible with C++ for
gcc-3.0. But then again, _none_ of the extant C++ compiler versions are
binary compatible, each needs its own libstdc++, so this is mostly a
non-issue.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

Gregory Maxwell <[EMAIL PROTECTED]> said:

[...]

> If you are going to upgrade, you should at least consider going to
> 2.4.0test-flavor-of-week, so that your crashes will at least contribute to
> Linux development. :)

Careful there! 2.4.0-test10-pre3 on i686 is the prime suspect in massive
reorganization of / here (had to reinstall several packages, and lost most
of root's account configuration), and it also nibbled at /usr/src (it
screwed up a directory, and I suspect it bit my gcc tree updated daily from
CVS, for which I have a backup).

Sorry, no further data.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

Jurgen Kramer <[EMAIL PROTECTED]> said:

> You can blame it on the compiler which is included with RH7.0. It's a
> pre-release version of some sort. It seems that the gcc people are not
> happy that RH included this version with RH7.

It is the *kernel's* fault, as far as can be ascertained now. The compiler
is stricter, and implements new optimizations, for which the kernel (being
only ever compiled with gcc) is just unprepared.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

c> 
"J . A . Magallon" <[EMAIL PROTECTED]> said:
> On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:

[...]

> I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> 2.96 what is broken.

2.95.2 has been working with kernels for quite some time. 2.96+ should (?)
work with latest 2.2.18-pre, at least patches in that direction will be
integrated by Alan.

[...]

> That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
> AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
> distro with that name. So users can know they are installing 2.2.18-pre, and
> not 2.2.17.

Red Hat 7.0's current kernel is 2.2.16-22, i.e., a heavily patched 2.2.16
announced as such.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Mike A. Harris]

On Sun, 22 Oct 2000, Jurgen Kramer wrote:

>Date: Sun, 22 Oct 2000 23:02:19 +0200
>From: Jurgen Kramer <[EMAIL PROTECTED]>
>To: Hamid Hashemi Golpayegani <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: Kernel 2.2.17 with RedHat 7 Problem !
>
>Hi,
>
>You can blame it on the compiler which is included with RH7.0.

This is incorrect and misleading.  The *KERNEL* has bugs that
require an older gcc.  Red Hat 7.0 includes an older gcc called
"kgcc" in order to compile kernels.

>It's a pre-release version of some sort.  It seems that the gcc
>people are not happy that RH included this version with RH7.

Which is irrelevant since Red Hat 7 includes kgcc which is
intended for kernel builds.

--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

[Mike A. Harris Linux tip #1 - 50 line mode]
Is the 80x25 line screen too small for you?  If you want more screen real
estate, you can set 50 column mode by editing your /etc/lilo.conf file, and 
adding a new line with "vga=ext" to the global section near the top.  Save
and exit, then run "lilo".  Next time you boot, you'll have a nice big 80x50 
screen.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Mike A. Harris]

On Mon, 23 Oct 2000, Hamid Hashemi Golpayegani wrote:

>Hi ,
>
>I have download kernel-2.2.17 from kernel.org and wanna to compile it under
>redhat 7 . when compiling start after few minutes show me this error message
>:
>
>make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
>gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
>raditional -c checksum.S -o checksum.o
>checksum.S:231: badly punctuated parameter list in #define
>checksum.S:237: badly punctuated parameter list in #define
>make[2]: *** [checksum.o] Error 1
>make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make[1]: *** [first_rule] Error 2
>make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make: *** [_dir_arch/i386/lib] Error 2
>
>I have install this kernel with same setting on RedHat 6.2 without any
>problem !
>Any idea ?

On Red Hat 7, you _MUST_ use the "kgcc" compiler to compile
kernels by editing the top level makefile and changing "gcc" to
"kgcc".


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

Need general help or technical support with Red Hat Linux 6.2?  Join the user 
support mailing list by sending a message to "[EMAIL PROTECTED]"
with the word "subscribe" on the subject line.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 01:00:14AM +0200, J . A . Magallon wrote:
> On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
> >  
> > > I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> > > 2.96 what is broken.
> > 
> > It compiles. Does it really work fine for all tasks and all people? Who
> > knows. It is know that your described configuration is not very well tested.
> > 
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage.
> 
> With the kernel, it refuses to compile somehthing (checksum.S) related with
> varargs in macros that is perefectly legal reading the info files for gcc.

The file is compiled with -traditional. The ellipses (for optionality) are a
GNU extension. The kernel contains the bug. Not gcc.

The kernel gurus agree that the kernel is broken and not GCC.
for example:
http://www.cs.helsinki.fi/linux/linux-kernel/2000-39/0495.html  

> > RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
> > with a 2.2.16-22 which is the richest description that the current framework
> > allows. They also ship a source package which contains each patch separate
> > from the source. 
> 
> The '22' there is the package version, not related to the gcc or kernel
> version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
> If they discover the left a pair of icons at home, the new package is
> thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
> But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
> If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
> If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.

Applying patches, adding scripts, etc sure sounds like a new version to me.

And the kernel that ships with RedHat 7 is 2.2.16 + patches and is
called (by them) 2.2.16-22 (which is what uname reports too). This kernel
has numerous advantages over 2.2.17.


> > 
> > The unfortunate consequence of the kernel versioning is most users can't
> > understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
> >
> 
> And should not be that way, because 17 usually includes all the patches to
> 16 that mutate it in -22, and even more.

It doesn't. 17 doesn't included 1/4 of what is in RedHat's 2.2.16-22 and
2.2.16-22 doesn't include everything in 2.2.17 (it's called testing and
avoiding shipping software they haven't tested).

RedHat has no control over what goes into the mainline 2.2.n. 

You are completely nuts if you think that distributions should wait
for a feature to appear in the mainline before including it in their
distribution. 

Doing so would certainly have a negative effect on the development of the
mainline kernel due to pressure to include features that are not ready for
the mainline.

Distributors have different goals from the mainline kernel developers, and
thus they ship different kernels.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
>  
> > I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> > 2.96 what is broken.
> 
> It compiles. Does it really work fine for all tasks and all people? Who
> knows. It is know that your described configuration is not very well tested.
> 
> If 2.96 is broken, I'd appreciate it if you would describe the breakage.

With the kernel, it refuses to compile somehthing (checksum.S) related with
varargs in macros that is perefectly legal reading the info files for gcc.
 
> RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
> with a 2.2.16-22 which is the richest description that the current framework
> allows. They also ship a source package which contains each patch separate
> from the source. 

The '22' there is the package version, not related to the gcc or kernel
version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
If they discover the left a pair of icons at home, the new package is
thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.

> 
> The unfortunate consequence of the kernel versioning is most users can't
> understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
>

And should not be that way, because 17 usually includes all the patches to
16 that mutate it in -22, and even more.

-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jan Dvorak]

On Sun, Oct 22, 2000 at 05:43:30PM -0400, Gregory Maxwell wrote:
> Due to bugs in the Linux kernel, it may only be compiled by certain versions
> of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
> (linux/Documentation/Changes). 
> 
> Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
> distributions are beginning to ship GCC 2.95 and later. Those distributions
> typically include an alternative gcc for compiling the kernel. RedHat has
> kgcc, and you should compile the kernel with that

I am using gcc 2.95.2 from its release, and i doesn't encounter any problems
on kernel compilation. Yes, i saw compiling problems on mailing lists, but i
think, that gcc 2.95.2 should be used widely as kernel compiler. It's better
than forcing users to have old 2.7.2.3 (even 2.95.2 is now year old), or to
have 2 compilers - one for 'normal' programs, second for compiling kernel.
It's more stable than gcc 2.95(.1), much more stable than pgcc,*cc, and its
millenia far from gcc 2.96 snapshot. It will be nice to point in Changes
*explicitly*, that gcc 2.96 will not work, that gcc 2.95.2 will work in most
cases, and if it will not (or if error in runtime), try to use egcs-whatever or
gcc 2.7.2.*. Gcc 2.95.2 (in fact anything > 2.7.2.3) is there compared as equal to
pgcc, which is unfair. 

Jan Dvorak <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Brian F. G. Bidulock]

-- Forwarded message --

-BEGIN PGP SIGNED MESSAGE-


It has come to our attention that some GNU/Linux distributions are
currently shipping with ``GCC 2.96''.

We would like to point out that GCC 2.96 is not a formal GCC release nor
will there ever be such a release.  Rather, GCC 2.96 has been the code-
name for our development branch that will eventually become GCC 3.0.

Current snapshots of GCC, and any version labeled 2.96, produce object
files that are not compatible with those produced by either GCC 2.95.2 or
the forthcoming GCC 3.0.  Therefore, programs built with these snapshots
will not be compatible with any official GCC release.  Actually, C and
Fortran code will probably be compatible, but code in other languages,
most notably C++ due to incompatibilities in symbol encoding (``mangling''),
the standard library and the application binary interface (ABI), is likely
to fail in some way.  Static linking against C++ libraries may make a
binary more portable, at the cost of increasing file size and memory use.

To avoid any confusion, we have bumped the version of our current
development branch to GCC 2.97.

Please note that both GCC 2.96 and 2.97 are development versions; we
do not recommend using them for production purposes.  Binaries built
using any version of GCC 2.96 or 2.97 will not be portable to systems
based on one of our regular releases.

If you encounter a bug in a compiler labeled 2.96, we suggest you
contact whoever supplied the compiler as we can not support 2.96
versions that were not issued by the GCC team.

Please see http://gcc.gnu.org/snapshots.html if you want to use our
latest snapshots.  We suggest you use 2.95.2 if you are uncertain.

The GCC Steering Committee 



- -- 
This article has been digitally signed by the moderator, using PGP.
http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
Send submissions for comp.os.linux.announce to: [EMAIL PROTECTED]
PLEASE remember a short description of the software and the LOCATION.
This group is archived at http://www.iki.fi/mjr/linux/cola.html

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBOeYfu1rUI/eHXJZ5AQFr/gP+Joi8J8CMFQ5k8hk9oCRuJKP0A9lnThrP
dKTbH2XnvVuBZ7ibcHenZHe1vVdRuxUyWxle4/Tg8QnQ2ON0smuPb2ibI0ie2W+7
RoCfe76XJ85e348JkkQgFSzSqsVbHV34KWp6H7ajyhTxRtONXCC07vxHT5I/GlTv
snmoSbKXPZg=
=yXqv
-END PGP SIGNATURE-

-- 
Brian F. G. Bidulock
[EMAIL PROTECTED]
http://www.openss7.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 12:15:08AM +0200, J . A . Magallon wrote:
> On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:
> > 
> > Due to bugs in the Linux kernel, it may only be compiled by certain versions
> > of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
> > (linux/Documentation/Changes). 
> 
> "Bugs" in the kernel are related with things like supposing that the compilers 
> makes things (such as alignment or padding in structs) in certain way, that 
> could be done in any other way, but are done 'that' way in gcc.

The standards state what you can and can not depend on. If you depend on
something that is unspecified then you are broken. Of course, the kernel is
special-case software so this kind of thing can be expected.
 
> I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> 2.96 what is broken.

It compiles. Does it really work fine for all tasks and all people? Who
knows. It is know that your described configuration is not very well tested.

If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
 
> That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
> AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
> distro with that name. So users can know they are installing 2.2.18-pre, and
> not 2.2.17.

RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
with a 2.2.16-22 which is the richest description that the current framework
allows. They also ship a source package which contains each patch separate
from the source. 

The reason they didn't call it 2.2.18-blah is because 2.2.17 didn't even
exist when they started their fork. Had they chosen to call their version
2.2.50 or whatever it would have caused needless confusion and perhaps
started a versioning war (i.e. SuSE with new 2.2.666 kernel! Mandrake with
2.2.777 kernel!).

They are rightfully (IMHO) letting the mainline developers increment the
kernel numbers while they denote their version with -nn. GCC doesn't have
the ability to -nn and because of that RedHat denoted their patched snapshot
2.96 and a frigging war ensued.

The unfortunate consequence of the kernel versioning is most users can't
understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:
> 
> Due to bugs in the Linux kernel, it may only be compiled by certain versions
> of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
> (linux/Documentation/Changes). 

"Bugs" in the kernel are related with things like supposing that the compilers 
makes things (such as alignment or padding in structs) in certain way, that 
could be done in any other way, but are done 'that' way in gcc.

> Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
> distributions are beginning to ship GCC 2.95 and later. Those distributions
> typically include an alternative gcc for compiling the kernel. RedHat has
> kgcc, and you should compile the kernel with that.
>
I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
2.96 what is broken.

> You might want to take this opportunity to rethink your decision to 'upgrade'
> your distributions kernel. Most distributions (including RedHat) ship
> patched kernels that include features and fixes not in the Linus kernels
> in order to better fit their users needs. If you install 2.2.17, you will
> lose: AGP support, USB support, greatly improved raid and NFS, and many other
> things. 
> 
> Any bug fixes that are in 2.2.17 have probably already been applied to your
> stock kernel.
> 
> (Alan has a 2.2.18pre that has most of these things included)
> 

That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
distro with that name. So users can know they are installing 2.2.18-pre, and
not 2.2.17.



-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Sun, 22 Oct 2000 22:54:32 Hamid Hashemi Golpayegani wrote:
> Hi ,
> 
> I have download kernel-2.2.17 from kernel.org and wanna to compile it under
> redhat 7 . when compiling start after few minutes show me this error message
> :
> 
> make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
> gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
> raditional -c checksum.S -o checksum.o
> checksum.S:231: badly punctuated parameter list in #define
> checksum.S:237: badly punctuated parameter list in #define

It seems to be a silly bug in 2.96 cpp. If your distro has something called kgcc
or egcs, install it and configure the kernel to be built with it (in main
Makefile
and in arch/i386/Makefile).

-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jurgen Kramer]

Hi,

You can blame it on the compiler which is included with RH7.0. It's a
pre-release version of
some sort. It seems that the gcc people are not happy that RH included this
version with RH7.

Cheers,

Jurgen


Hamid Hashemi Golpayegani wrote:

> Hi ,
>
> I have download kernel-2.2.17 from kernel.org and wanna to compile it under
> redhat 7 . when compiling start after few minutes show me this error message
> :
>
> make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
> gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
> raditional -c checksum.S -o checksum.o
> checksum.S:231: badly punctuated parameter list in #define
> checksum.S:237: badly punctuated parameter list in #define
> make[2]: *** [checksum.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
> make: *** [_dir_arch/i386/lib] Error 2
>
> I have install this kernel with same setting on RedHat 6.2 without any
> problem !
> Any idea ?
>
> Thank You
> Hamid Hashemi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 12:24:32AM +0330, Hamid Hashemi Golpayegani wrote:
> Hi ,
> 
> I have download kernel-2.2.17 from kernel.org and wanna to compile it under
> redhat 7 . when compiling start after few minutes show me this error message
> :

Due to bugs in the Linux kernel, it may only be compiled by certain versions
of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
(linux/Documentation/Changes). 

Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
distributions are beginning to ship GCC 2.95 and later. Those distributions
typically include an alternative gcc for compiling the kernel. RedHat has
kgcc, and you should compile the kernel with that.

You might want to take this opportunity to rethink your decision to 'upgrade'
your distributions kernel. Most distributions (including RedHat) ship
patched kernels that include features and fixes not in the Linus kernels
in order to better fit their users needs. If you install 2.2.17, you will
lose: AGP support, USB support, greatly improved raid and NFS, and many other
things. 

Any bug fixes that are in 2.2.17 have probably already been applied to your
stock kernel.

(Alan has a 2.2.18pre that has most of these things included)

You will likely get the best support and stability from the kernel the
distributor recommends you run.

If you are going to upgrade, you should at least consider going to
2.4.0test-flavor-of-week, so that your crashes will at least contribute to
Linux development. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

Hamid,

RedHat includes two versions of gcc.  gcc-2.96 is a developmental snapshot 
of the compiler project and is not able to build a kernel.  Also included 
is kgcc, as in KernelGCC, which is what you should be using.  If you don't 
have the kgcc...rpm installed, install that and use it.

David

At 04:54 PM 10/22/00, Hamid Hashemi Golpayegani wrote:
>Hi ,
>
>I have download kernel-2.2.17 from kernel.org and wanna to compile it under
>redhat 7 . when compiling start after few minutes show me this error message
>:
>
>make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
>gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
>raditional -c checksum.S -o checksum.o
>checksum.S:231: badly punctuated parameter list in #define
>checksum.S:237: badly punctuated parameter list in #define
>make[2]: *** [checksum.o] Error 1
>make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make[1]: *** [first_rule] Error 2
>make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make: *** [_dir_arch/i386/lib] Error 2
>
>I have install this kernel with same setting on RedHat 6.2 without any
>problem !
>Any idea ?
>
>Thank You
>Hamid Hashemi
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>Please read the FAQ at http://www.tux.org/lkml/


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Kernel 2.2.17 with RedHat 7 Problem !

[Hamid Hashemi Golpayegani]

Hi ,

I have download kernel-2.2.17 from kernel.org and wanna to compile it under
redhat 7 . when compiling start after few minutes show me this error message
:

make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
raditional -c checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2

I have install this kernel with same setting on RedHat 6.2 without any
problem !
Any idea ?

Thank You
Hamid Hashemi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Kernel 2.2.17 with RedHat 7 Problem !

[Hamid Hashemi Golpayegani]

Hi ,

I have download kernel-2.2.17 from kernel.org and wanna to compile it under
redhat 7 . when compiling start after few minutes show me this error message
:

make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
raditional -c checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2

I have install this kernel with same setting on RedHat 6.2 without any
problem !
Any idea ?

Thank You
Hamid Hashemi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

Hamid,

RedHat includes two versions of gcc.  gcc-2.96 is a developmental snapshot 
of the compiler project and is not able to build a kernel.  Also included 
is kgcc, as in KernelGCC, which is what you should be using.  If you don't 
have the kgcc...rpm installed, install that and use it.

David

At 04:54 PM 10/22/00, Hamid Hashemi Golpayegani wrote:
Hi ,

I have download kernel-2.2.17 from kernel.org and wanna to compile it under
redhat 7 . when compiling start after few minutes show me this error message
:

make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
raditional -c checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2

I have install this kernel with same setting on RedHat 6.2 without any
problem !
Any idea ?

Thank You
Hamid Hashemi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 12:24:32AM +0330, Hamid Hashemi Golpayegani wrote:
 Hi ,
 
 I have download kernel-2.2.17 from kernel.org and wanna to compile it under
 redhat 7 . when compiling start after few minutes show me this error message
 :

Due to bugs in the Linux kernel, it may only be compiled by certain versions
of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
(linux/Documentation/Changes). 

Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
distributions are beginning to ship GCC 2.95 and later. Those distributions
typically include an alternative gcc for compiling the kernel. RedHat has
kgcc, and you should compile the kernel with that.

You might want to take this opportunity to rethink your decision to 'upgrade'
your distributions kernel. Most distributions (including RedHat) ship
patched kernels that include features and fixes not in the Linus kernels
in order to better fit their users needs. If you install 2.2.17, you will
lose: AGP support, USB support, greatly improved raid and NFS, and many other
things. 

Any bug fixes that are in 2.2.17 have probably already been applied to your
stock kernel.

(Alan has a 2.2.18pre that has most of these things included)

You will likely get the best support and stability from the kernel the
distributor recommends you run.

If you are going to upgrade, you should at least consider going to
2.4.0test-flavor-of-week, so that your crashes will at least contribute to
Linux development. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jurgen Kramer]

Hi,

You can blame it on the compiler which is included with RH7.0. It's a
pre-release version of
some sort. It seems that the gcc people are not happy that RH included this
version with RH7.

Cheers,

Jurgen


Hamid Hashemi Golpayegani wrote:

 Hi ,

 I have download kernel-2.2.17 from kernel.org and wanna to compile it under
 redhat 7 . when compiling start after few minutes show me this error message
 :

 make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
 gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
 raditional -c checksum.S -o checksum.o
 checksum.S:231: badly punctuated parameter list in #define
 checksum.S:237: badly punctuated parameter list in #define
 make[2]: *** [checksum.o] Error 1
 make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
 make[1]: *** [first_rule] Error 2
 make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
 make: *** [_dir_arch/i386/lib] Error 2

 I have install this kernel with same setting on RedHat 6.2 without any
 problem !
 Any idea ?

 Thank You
 Hamid Hashemi

 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Sun, 22 Oct 2000 22:54:32 Hamid Hashemi Golpayegani wrote:
 Hi ,
 
 I have download kernel-2.2.17 from kernel.org and wanna to compile it under
 redhat 7 . when compiling start after few minutes show me this error message
 :
 
 make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
 gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
 raditional -c checksum.S -o checksum.o
 checksum.S:231: badly punctuated parameter list in #define
 checksum.S:237: badly punctuated parameter list in #define

It seems to be a silly bug in 2.96 cpp. If your distro has something called kgcc
or egcs, install it and configure the kernel to be built with it (in main
Makefile
and in arch/i386/Makefile).

-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:
 
 Due to bugs in the Linux kernel, it may only be compiled by certain versions
 of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
 (linux/Documentation/Changes). 

"Bugs" in the kernel are related with things like supposing that the compilers 
makes things (such as alignment or padding in structs) in certain way, that 
could be done in any other way, but are done 'that' way in gcc.

 Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
 distributions are beginning to ship GCC 2.95 and later. Those distributions
 typically include an alternative gcc for compiling the kernel. RedHat has
 kgcc, and you should compile the kernel with that.

I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
2.96 what is broken.

 You might want to take this opportunity to rethink your decision to 'upgrade'
 your distributions kernel. Most distributions (including RedHat) ship
 patched kernels that include features and fixes not in the Linus kernels
 in order to better fit their users needs. If you install 2.2.17, you will
 lose: AGP support, USB support, greatly improved raid and NFS, and many other
 things. 
 
 Any bug fixes that are in 2.2.17 have probably already been applied to your
 stock kernel.
 
 (Alan has a 2.2.18pre that has most of these things included)
 

That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
distro with that name. So users can know they are installing 2.2.18-pre, and
not 2.2.17.



-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 12:15:08AM +0200, J . A . Magallon wrote:
 On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:
  
  Due to bugs in the Linux kernel, it may only be compiled by certain versions
  of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
  (linux/Documentation/Changes). 
 
 "Bugs" in the kernel are related with things like supposing that the compilers 
 makes things (such as alignment or padding in structs) in certain way, that 
 could be done in any other way, but are done 'that' way in gcc.

The standards state what you can and can not depend on. If you depend on
something that is unspecified then you are broken. Of course, the kernel is
special-case software so this kind of thing can be expected.
 
 I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
 2.96 what is broken.

It compiles. Does it really work fine for all tasks and all people? Who
knows. It is know that your described configuration is not very well tested.

If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
 
 That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
 AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
 distro with that name. So users can know they are installing 2.2.18-pre, and
 not 2.2.17.

RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
with a 2.2.16-22 which is the richest description that the current framework
allows. They also ship a source package which contains each patch separate
from the source. 

The reason they didn't call it 2.2.18-blah is because 2.2.17 didn't even
exist when they started their fork. Had they chosen to call their version
2.2.50 or whatever it would have caused needless confusion and perhaps
started a versioning war (i.e. SuSE with new 2.2.666 kernel! Mandrake with
2.2.777 kernel!).

They are rightfully (IMHO) letting the mainline developers increment the
kernel numbers while they denote their version with -nn. GCC doesn't have
the ability to -nn and because of that RedHat denoted their patched snapshot
2.96 and a frigging war ensued.

The unfortunate consequence of the kernel versioning is most users can't
understand that 2.2.16-22  2.2.17 in terms of usability for most users.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Brian F. G. Bidulock]

-- Forwarded message --

-BEGIN PGP SIGNED MESSAGE-


It has come to our attention that some GNU/Linux distributions are
currently shipping with ``GCC 2.96''.

We would like to point out that GCC 2.96 is not a formal GCC release nor
will there ever be such a release.  Rather, GCC 2.96 has been the code-
name for our development branch that will eventually become GCC 3.0.

Current snapshots of GCC, and any version labeled 2.96, produce object
files that are not compatible with those produced by either GCC 2.95.2 or
the forthcoming GCC 3.0.  Therefore, programs built with these snapshots
will not be compatible with any official GCC release.  Actually, C and
Fortran code will probably be compatible, but code in other languages,
most notably C++ due to incompatibilities in symbol encoding (``mangling''),
the standard library and the application binary interface (ABI), is likely
to fail in some way.  Static linking against C++ libraries may make a
binary more portable, at the cost of increasing file size and memory use.

To avoid any confusion, we have bumped the version of our current
development branch to GCC 2.97.

Please note that both GCC 2.96 and 2.97 are development versions; we
do not recommend using them for production purposes.  Binaries built
using any version of GCC 2.96 or 2.97 will not be portable to systems
based on one of our regular releases.

If you encounter a bug in a compiler labeled 2.96, we suggest you
contact whoever supplied the compiler as we can not support 2.96
versions that were not issued by the GCC team.

Please see http://gcc.gnu.org/snapshots.html if you want to use our
latest snapshots.  We suggest you use 2.95.2 if you are uncertain.

The GCC Steering Committee http://gcc.gnu.org/steering.html



- -- 
This article has been digitally signed by the moderator, using PGP.
http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
Send submissions for comp.os.linux.announce to: [EMAIL PROTECTED]
PLEASE remember a short description of the software and the LOCATION.
This group is archived at http://www.iki.fi/mjr/linux/cola.html

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBOeYfu1rUI/eHXJZ5AQFr/gP+Joi8J8CMFQ5k8hk9oCRuJKP0A9lnThrP
dKTbH2XnvVuBZ7ibcHenZHe1vVdRuxUyWxle4/Tg8QnQ2ON0smuPb2ibI0ie2W+7
RoCfe76XJ85e348JkkQgFSzSqsVbHV34KWp6H7ajyhTxRtONXCC07vxHT5I/GlTv
snmoSbKXPZg=
=yXqv
-END PGP SIGNATURE-

-- 
Brian F. G. Bidulock
[EMAIL PROTECTED]
http://www.openss7.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
  
  I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
  2.96 what is broken.
 
 It compiles. Does it really work fine for all tasks and all people? Who
 knows. It is know that your described configuration is not very well tested.
 
 If 2.96 is broken, I'd appreciate it if you would describe the breakage.

With the kernel, it refuses to compile somehthing (checksum.S) related with
varargs in macros that is perefectly legal reading the info files for gcc.
 
 RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
 with a 2.2.16-22 which is the richest description that the current framework
 allows. They also ship a source package which contains each patch separate
 from the source. 

The '22' there is the package version, not related to the gcc or kernel
version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
If they discover the left a pair of icons at home, the new package is
thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.

 
 The unfortunate consequence of the kernel versioning is most users can't
 understand that 2.2.16-22  2.2.17 in terms of usability for most users.


And should not be that way, because 17 usually includes all the patches to
16 that mutate it in -22, and even more.

-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jan Dvorak]

On Sun, Oct 22, 2000 at 05:43:30PM -0400, Gregory Maxwell wrote:
 Due to bugs in the Linux kernel, it may only be compiled by certain versions
 of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
 (linux/Documentation/Changes). 
 
 Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
 distributions are beginning to ship GCC 2.95 and later. Those distributions
 typically include an alternative gcc for compiling the kernel. RedHat has
 kgcc, and you should compile the kernel with that

I am using gcc 2.95.2 from its release, and i doesn't encounter any problems
on kernel compilation. Yes, i saw compiling problems on mailing lists, but i
think, that gcc 2.95.2 should be used widely as kernel compiler. It's better
than forcing users to have old 2.7.2.3 (even 2.95.2 is now year old), or to
have 2 compilers - one for 'normal' programs, second for compiling kernel.
It's more stable than gcc 2.95(.1), much more stable than pgcc,*cc, and its
millenia far from gcc 2.96 snapshot. It will be nice to point in Changes
*explicitly*, that gcc 2.96 will not work, that gcc 2.95.2 will work in most
cases, and if it will not (or if error in runtime), try to use egcs-whatever or
gcc 2.7.2.*. Gcc 2.95.2 (in fact anything  2.7.2.3) is there compared as equal to
pgcc, which is unfair. 

Jan Dvorak [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Mike A. Harris]

On Mon, 23 Oct 2000, Hamid Hashemi Golpayegani wrote:

Hi ,

I have download kernel-2.2.17 from kernel.org and wanna to compile it under
redhat 7 . when compiling start after few minutes show me this error message
:

make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
raditional -c checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2

I have install this kernel with same setting on RedHat 6.2 without any
problem !
Any idea ?

On Red Hat 7, you _MUST_ use the "kgcc" compiler to compile
kernels by editing the top level makefile and changing "gcc" to
"kgcc".


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

Need general help or technical support with Red Hat Linux 6.2?  Join the user 
support mailing list by sending a message to "[EMAIL PROTECTED]"
with the word "subscribe" on the subject line.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Mike A. Harris]

On Sun, 22 Oct 2000, Jurgen Kramer wrote:

Date: Sun, 22 Oct 2000 23:02:19 +0200
From: Jurgen Kramer [EMAIL PROTECTED]
To: Hamid Hashemi Golpayegani [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Subject: Re: Kernel 2.2.17 with RedHat 7 Problem !

Hi,

You can blame it on the compiler which is included with RH7.0.

This is incorrect and misleading.  The *KERNEL* has bugs that
require an older gcc.  Red Hat 7.0 includes an older gcc called
"kgcc" in order to compile kernels.

It's a pre-release version of some sort.  It seems that the gcc
people are not happy that RH included this version with RH7.

Which is irrelevant since Red Hat 7 includes kgcc which is
intended for kernel builds.

--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

[Mike A. Harris Linux tip #1 - 50 line mode]
Is the 80x25 line screen too small for you?  If you want more screen real
estate, you can set 50 column mode by editing your /etc/lilo.conf file, and 
adding a new line with "vga=ext" to the global section near the top.  Save
and exit, then run "lilo".  Next time you boot, you'll have a nice big 80x50 
screen.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

Jurgen Kramer [EMAIL PROTECTED] said:

 You can blame it on the compiler which is included with RH7.0. It's a
 pre-release version of some sort. It seems that the gcc people are not
 happy that RH included this version with RH7.

It is the *kernel's* fault, as far as can be ascertained now. The compiler
is stricter, and implements new optimizations, for which the kernel (being
only ever compiled with gcc) is just unprepared.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

"Brian F. G. Bidulock" [EMAIL PROTECTED] said:
 It has come to our attention that some GNU/Linux distributions are
 currently shipping with ``GCC 2.96''.

Please, not again!

Red Hat 7.0's "GCC 2.96" is binary compatible for C with all past and
future versions. It will probably not be binary compatible with C++ for
gcc-3.0. But then again, _none_ of the extant C++ compiler versions are
binary compatible, each needs its own libstdc++, so this is mostly a
non-issue.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

Gregory Maxwell [EMAIL PROTECTED] said:

[...]

 If you are going to upgrade, you should at least consider going to
 2.4.0test-flavor-of-week, so that your crashes will at least contribute to
 Linux development. :)

Careful there! 2.4.0-test10-pre3 on i686 is the prime suspect in massive
reorganization of / here (had to reinstall several packages, and lost most
of root's account configuration), and it also nibbled at /usr/src (it
screwed up a directory, and I suspect it bit my gcc tree updated daily from
CVS, for which I have a backup).

Sorry, no further data.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

c 
"J . A . Magallon" [EMAIL PROTECTED] said:
 On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:

[...]

 I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
 2.96 what is broken.

2.95.2 has been working with kernels for quite some time. 2.96+ should (?)
work with latest 2.2.18-pre, at least patches in that direction will be
integrated by Alan.

[...]

 That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
 AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
 distro with that name. So users can know they are installing 2.2.18-pre, and
 not 2.2.17.

Red Hat 7.0's current kernel is 2.2.16-22, i.e., a heavily patched 2.2.16
announced as such.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Sun, Oct 22, 2000 at 10:12:06PM -0300, Horst von Brand wrote:
 Gregory Maxwell [EMAIL PROTECTED] said: 
 [...]
  If you are going to upgrade, you should at least consider going to
  2.4.0test-flavor-of-week, so that your crashes will at least contribute to
  Linux development. :)
 
 Careful there! 2.4.0-test10-pre3 on i686 is the prime suspect in massive
 reorganization of / here (had to reinstall several packages, and lost most
 of root's account configuration), and it also nibbled at /usr/src (it
 screwed up a directory, and I suspect it bit my gcc tree updated daily from
 CVS, for which I have a backup).

Thanks. After four years of participating on this list, I guess I've come to
ignore the occasional devel-kernel-eats-my-filesystem. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

At 09:14 PM 10/22/00, Horst von Brand wrote:
Jurgen Kramer [EMAIL PROTECTED] said:

  You can blame it on the compiler which is included with RH7.0. It's a
  pre-release version of some sort. It seems that the gcc people are not
  happy that RH included this version with RH7.

It is the *kernel's* fault, as far as can be ascertained now. The compiler
is stricter, and implements new optimizations, for which the kernel (being
only ever compiled with gcc) is just unprepared.

The problem, as I understand it, is that gcc-2.96 handles language 
constructs slightly different than older compilers.  This is a preprocessor 
change, not an optimization problem.

To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
worked with compilers (some years ago), I always took it as an article of 
faith that the same answer(s) would be generated whether optimization was 
turned on or not.  Optimization should always be a way to do a task either 
quicker (fewer instructions executing, less executing time, etc) or shorter 
(less memory needed for the instructions).  Optimization should never, 
never give a different result.  Having new optimizations break an executing 
program is simply wrong.

David


--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Michael Meissner]

On Sun, Oct 22, 2000 at 11:16:36PM -0400, David Relson wrote:
 At 09:14 PM 10/22/00, Horst von Brand wrote:
 Jurgen Kramer [EMAIL PROTECTED] said:
 
   You can blame it on the compiler which is included with RH7.0. It's a
   pre-release version of some sort. It seems that the gcc people are not
   happy that RH included this version with RH7.
 
 It is the *kernel's* fault, as far as can be ascertained now. The compiler
 is stricter, and implements new optimizations, for which the kernel (being
 only ever compiled with gcc) is just unprepared.
 
 The problem, as I understand it, is that gcc-2.96 handles language 
 constructs slightly different than older compilers.  This is a preprocessor 
 change, not an optimization problem.
 
 To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
 worked with compilers (some years ago), I always took it as an article of 
 faith that the same answer(s) would be generated whether optimization was 
 turned on or not.  Optimization should always be a way to do a task either 
 quicker (fewer instructions executing, less executing time, etc) or shorter 
 (less memory needed for the instructions).  Optimization should never, 
 never give a different result.  Having new optimizations break an executing 
 program is simply wrong.

Ummm, that should read "Having new optimizations break a correct exeucting
program...".  For example, the following program:

#include stdio.h

int main(){
  int i;
  printf ("i = %d\n", i);
  return 0;
}

will necessarily print different values for i, depending on the optimization
level, what was on the stack and in the registers when main started, and
possibly other criteria.  Just because a program is executing, it doesn't mean
it is correct.

Both the kernel and the compiler are large complex pieces of software, and
almost certainly have bugs in them, and over the years, I have certainly found
some of these bugs as I use new versions of each.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/