[OpenAFS-devel] Re: OpenAFS-devel digest, Vol 1 #25 - 13 msgs

[Derrick J Brashear]

On Mon, 11 Dec 2000, Jeremy Katz wrote:

> On Monday, December 11 2000, Derrick J Brashear said:
> > On Mon, 11 Dec 2000, R. Lindsay Todd wrote:
> > > I modified the spec file to add CC=kgcc, and rebuilt.  It is
> > > definitely using kgcc now, but it still fails on kdump.c.  (You
> > > can't build this with the normal gcc, either.)  But the make
> > > progresses enough that you still have a usable client, and if you
> > > make the changes I mention to protect against the "make" exit code,
> > > the RPMs build.
> [snip build error] 
> > The right way to fix the problem will involve a bit of work, but will fix
> > for gcc and kgcc alike. /usr/include/{asm,linux,scsi} are not linked to
> > /usr/src/linux/include/{asm,linux,scsi} but instead are coming from
> > elsewhere. I need to get more details to figure out exactly why this is
> > happening, but my suspicion is that if you change CC to
> > "gcc -I/usr/src/linux-$LINUX_VERS/include" and build kdump, it will work.
> > When I have more details, I will share.
> 
> The /usr/include/{asm,linux,scsi} directories are (correctly according
> to Linus) the headers which glibc was built with as opposed to the
> headers for the current kernel.  This is more correct as you do
> generally care about what features your glibc supports when compiling
> programs for userspace than what your kernel could theoretically support
> if you recompiled glibc.  

Which is fine, but..

> The obvious exception to this is for modules and other programs which
> need information on kernel internals, but these should be told where to
> look for the actual kernel source.  

kdump is one of those.

-D