Kernel Compiler missmatches

[Scott Kitterman]

On Tue, 17 Feb 2009 14:07:23 +0000 Colin Watson <cjwatson at ubuntu.com> wrote:
>On Fri, Feb 13, 2009 at 09:33:37AM -0500, Scott Kitterman wrote:
>> On Fri, 13 Feb 2009 12:06:56 +0000 Andy Whitcroft <apw at canonical.com> 
wrote:
>> >We have a couple of reports indicating that following an update to Hardy
>> >their exernal modules no longer build.  Specifically those modules fail
>> >to build because the version of gcc used to build the kernel and the one
>> >installed and available to build the modules does not match.  The kernel
>> >highly recommends you use the same version, and most external modules
>> >sensibly enforce this.
>> >
>> >This missmatch has been triggered in Hardy because we recently did a
>> >security update to the kernel.  That was built in the -security 
environment
>> >which necesarily lacks any updates from -updates, and therefore has the
>> >released version of gcc.  This kernel was then pocket copied to 
-updates.
>> >At this point users of -updates have a kernel which was compiled with an
>> >older compiler than the one they have.  This is not desirable.
>> >
>> >There seem to be several simple options here:
>> >
>> >1) expect the users to build their own kernels if they want to use
>> >   external modules, or
>> >2) update gcc in -security, and always do so, or
>> >3) have separate kernel builds for each pocket (rather than pocket 
copying
>> >   the -security update into -updates, upload it there separatly with a
>> >   higher upload number).
>> >
>> >I guess the security team is best placed to evaluate the safety or
>> >otherwise of (2).
>> 
>> It has to be #1 or #3.  If -security were built with the -updates gcc, 
then 
>> you've just reversed the problem and broken things for people who don't 
use 
>> -updates.  This is a supported use case (the reason -security is built 
from 
>> -release).
>
>My suggestion was #2, because this means that (a) future kernel builds
>happen with the newer gcc and (b) users who don't use -updates get the
>new gcc so that their local module compiles will work. Furthermore I
>think it's probably not particularly good to have divergent versions of
>gcc between -security and -updates anyway.
>
>You seem to discard #2, but your objections don't match my understanding
>of this option. Do we have different understandings? I'm saying that we
>should copy gcc into -security; you're objecting to building -security
>using -updates, which isn't what Andy's #2 says.

I misread it the first time.  Sorry about that.

>I do think, given the known state of the kernel, that we should update
>gcc in -security shortly before a kernel ABI change in -security, to
>minimise practical problems. Furthermore, in light of this problem we
>should avoid changing the visible upstream version of gcc in future
>post-release updates, even if it is necessary to backport some upstream
>changes.
>
OK.  Nevermind about my objection.

Scott K