[MPlayer-users] Compile with new kernel

[D Richard Felker III]

On Fri, Aug 01, 2003 at 12:49:05PM +0300, Tuukka Toivonen wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> 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).

And you have no rational basis on which to think this; you just cite
authority of other people. Great foundation for a "strong" belief.

> 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).

I couldn't care less what Linus says and I certainly don't consider
him a god.

> 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.

Yes it will 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.

This is stupid. An OS is supposed to provide headers with the
necessary #defines and structs for calling its ioctl's!! Sure we could
include such stuff for Linux if we wanted, but what then? Include
headers for every other kernel as well?? No.

> >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

These are DIFFERENT HEADERS we're talking about. Some headers are
interfaces to syscalls. Others are interfaces to ioctl's for special
devices. glibc has its own version of the former, but NOT THE LATTER,
and should never have the latter because it's bad design.

> 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.

Do you even know what the ways to 'communicate with the kernel' are?

> >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...

Names? It's probably broken programs that include kernel headers they
should NEVER include in the first place (so it shouldn't matter what
version is installed). The only kernel headers you should include
(stuff like fb.h, soundcard.h, videodev.h, etc.) will not cause such
conflicts.

> 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 developers know how to make a bloated crappy libc that needs 30
megs of junk to do locale, when uclibc can do the same stuff in
trivial space. Also keep in mind that a single program, linked against
glibc, can be 1 or 2 megs resident, whereas when it's just relinked
against uclibc, it shrinks to 100k. Feel free to offer explanations,
but I will maintain that this is NOT competent libc design.

> glibc doesn't include files from kernel source directory (ok, didn't check
> that, if I'm wrong then let me shoot myself).

Right, and guess what?? That means there's no rational reason that you
should use the same kernel headers glibc was compiled with.


Rich