Re: Bug#325484: udev >= 0.060-1 and kernels >= 2.6.12
On Tue, Aug 30, 2005 at 08:23:02PM -0400, Roberto C. Sanchez wrote:
> On Tue, Aug 30, 2005 at 04:59:48PM -0700, Steve Langasek wrote:
> >
> > > Becuase I roll my own kernel. If I upgrade the kernel with gcc-3.3
> > > (currently the Sarge default) and then upgrade to Etch (which will have
> > > gcc-4.0 for a default) I will run into problems if I decide to add new
> > > modules to my kernel. Thus, those with a self-compiled kernel are in a
> > > situation where you can a) dist-upgrade without first upgrading the
> > > kernel and risk breakage; or b) upgrade the kernel twice. Once before
> > > and once after. I suppose that it is possible to build the new kernel
> > > inside of a chroot (or sbuild or pbuilder) if kernel-package is being
> > > used.
> >
> > > I am simply pointing out that there is a potential issue that needs to
> > > at least be addressed in the release notes.
> >
> > Ah, yes. I really don't understand why the kernel embeds the gcc
> > version into its version-matching logic, but I've run into this problem
> > as well. I agree that it warrants documenting, though I also suspect
> > that most users running self-compiled 2.6 kernels are going to be
> > running something a bit newer than 2.6.8 anyway.
> >
> I also don't understand why the gcc version is an issue. I mean, you
> can compile a library with one version of gcc and link to it when
> compiling a program with a different version of gcc. We are even
> talking about C, which AFAICT doesn't suffer the same binary
> compatibility issues as C++.
The kernel enables or disables many different things depending on the
version of gcc to work around different issues. Because of this, the
main kernel, and all kernel modules must be built with the exact same
version of gcc, otherwise very bad things can happen.
greg k-h
Reply to: