[MPlayer-users] Compile with new kernel

[Tuukka Toivonen]

On Thu, 31 Jul 2003, D Richard Felker III wrote:

>That's the standard location, but it's irrelevant. The point is that
>/usr/include/linux should not be some outdated kernel headers that
>came with your distro, but the latest kernel you're actually using.
>Whether you make a symlink, compy each time you upgrade kernel, or
>whatever...

This is getting a bit like flamewar, but I'll reply once anyway. I strongly
think that /usr/include/linux should _not_ be a symlink to the kernel
source tree, but include copy of (possibly) older kernel headers (or be a
symlink to such).

The main reason is that I remember Linus the God saying this, but surely
there are other good reasons too. (If you insist, I could try digging the
link about Linus).

Now, it seems you're saying otherwise so that programs (mplayer) could
include the header files containing the latest kernel features. But what if
user is compiling the program with older kernel and copying it to another
computer with newer kernel? It wouldn't work.

The correct way is to copy kernel header files into the program (mplayer)
source tree. This makes sure the latest features are always available.

>WTF is this obsession with glibc??? If glibc really depends on kernel
>headers, then it needs to be *fixed* (or better yet replaced with a

glibc should include a copy of kernel headers (or compatible headers
written from scratch, but that would be much more work). I believe recent
glibces also do this (used to be different, I think, with 5.x or
something). And of course it has to do this to be able to communicate with
the kernel.

>Anyway, like both Gabu and I said, we have not seen such a problem in
>6 years of compiling everything from source, so I don't believe the
>problem actually exists. If you insist that it does, perhaps you could

Well I have. umsdos tools include(d) headers directly from kernel source,
which made the compile to fail. I had to copy the headers manually from
older kernels, then it worked. Probably I have encountered other cases too
but just don't remember right now...

If you don't have problems, it doesn't mean other people wouldn't have.

>This isn't a kernel issue but a userspace/libc issue, so it doesn't
>matter who knows more about the kernel.

...I believe glibc developers know more about libc than you, and see what:
glibc doesn't include files from kernel source directory (ok, didn't check
that, if I'm wrong then let me shoot myself).