kbuild 2.5 preventing mixture of compilers

kbuild 2.5 preventing mixture of compilers

[Keith Owens]

FYI, kbuild 2.5 will check that all the kernel and modules were
compiled with the same version of gcc, in particular they must all have
the same value of

  $(CC) -v 2>&1 | sed -ne '1s:.*/\([^/]*/[^/]*\)/[^/]\+$:\1:p'

e.g. i386-redhat-linux/2.96

Minor version data such as build date is assumed to be irrelevant.
Anybody who makes significant changes to compiler output without
changing the version number gets what they deserve.

Modules built with a different compiler from the kernel will not load
unless they are forced with insmod -f.

Is this going to cause problems for anybody?  I see no justification
for mixing kernel objects built by different compilers and I know of
problems that have been caused by doing so.

Re: kbuild 2.5 preventing mixture of compilers

[Lee Packham]

IMHO, that is a good idea... almost.

What about companies that maintain closed source driver modules for their 
hardware?

I know a lot of people here will say, 'well they should open source them 
then'. However, some companies don't want to for their own reasons and 
this 'could' blow them out the water a bit and affect end users.

>From a stability point of view, this may seem like an excellent idea. I'm 
just scared that this could put companies off producing driver modules for 
their hardware.

Lee Packham

> FYI, kbuild 2.5 will check that all the kernel and modules were
> compiled with the same version of gcc, in particular they must all have
> the same value of
> 
>   $(CC) -v 2>&1 | sed -ne '1s:.*/\([^/]*/[^/]*\)/[^/]\+$:\1:p'
> 
> e.g. i386-redhat-linux/2.96
> 
> Minor version data such as build date is assumed to be irrelevant.
> Anybody who makes significant changes to compiler output without
> changing the version number gets what they deserve.
> 
> Modules built with a different compiler from the kernel will not load
> unless they are forced with insmod -f.
> 
> Is this going to cause problems for anybody?  I see no justification
> for mixing kernel objects built by different compilers and I know of
> problems that have been caused by doing so.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild 2.5 preventing mixture of compilers

[arjan]

In article <2644.192.168.2.1.1004602385.squirrel@mail.mswinxp.net> you wrote:
> IMHO, that is a good idea... almost.

> What about companies that maintain closed source driver modules for their 
> hardware?

> I know a lot of people here will say, 'well they should open source them 
> then'. However, some companies don't want to for their own reasons and 
> this 'could' blow them out the water a bit and affect end users.

If a different compiler version is known to break (and Keith says he has
seen that in practice, and I can see it happen as well given that a few
kernel headers depend on compiler version), the vendor in question is better
off being informed about the incompatibility. He _already_ has to have an
exact match on the kernel version and the other symbols, so adding the
compiler to that is not an extra burden, just a "oh we goofed" prevention..