[YBA] kernel compile errors with GCC >= 4.6

[YBA] kernel compile errors with GCC >= 4.6

Nadav Har'El nyh at math.technion.ac.il
Thu Apr 5 14:03:46 IDT 2012


On Thu, Apr 05, 2012, Jonathan Ben Avraham wrote about "Re: [YBA] kernel compile errors with GCC >= 4.6":
> Hi Nadav,
> From a technical viewpoint of view, forward compatibility is not
> feasible in software. 3.4 might compile fine now under GCC 3.2, but
> it is likely to break in some future version of GCC that, for
> example, warns on "goto", or more realistically, warns on the string
> "-" that might be a dash, hyphen, or minus depending on the
> interpretation of your editor.

I think this is exactly what I said :-) Because "warnings" are *not*
specified in the C standard, and are not *forward* compatible (a new
version might suddenly cry new warnings), they should not be part of the
normal build process of users, unless your goal is to frustrate users
and prevent them from succeeding in the compilation.

On the other hand, the C language itself (not the warnings) is
more-or-less guaranteed to be forward compatible. If Linux 3.3 can
compiled on GCC 4.7, it is almost certain that in 10 years, GCC 6.0 will
also compile it just fine. That is, assuming -Wall -Werror isn't turned
on :-)

> I think that it would be best if kernels were released with the list
> of compiler types and versions under which they were tested before
> release. It is not useful to pretend that there is no necessary
> connection between particular GCC versions and particular kernel
> versions. The compiler is in fact a part of the running kernel.

You are right, but you can't really claiming that you "tested" Linux 3.3
with GCC 4.7, without also saying on which machine you ran it on,
exactly which ".config" you had, and so on. In the specific example you
gave, GCC 4.7 actually did work - but not with a specific .config
setting.

I think such a list will be awkward, and not very useful. It is better
to just say that it "should" work on any GCC > 3.2, and if it doesn't,
it needs to be fixed. And preferably not in a way that will cause a new
breakages every time a new GCC is released.

-- 
Nadav Har'El                        |                   Thursday, Apr 5 2012, 
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Debugging: the art of removing bugs.
http://nadav.harel.org.il           |Programming: the art of inserting them.



More information about the Linux-il mailing list