[MPlayer-users] Compile with new kernel

[D Richard Felker III]

On Thu, Jul 31, 2003 at 08:22:03PM +0200, Gábor Lénárt wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Thu, Jul 31, 2003 at 07:00:18PM +0200, gabucino at mplayerhq.hu wrote:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> 
> > > Arghh, this is BAD. It shouldn't be done this way!
> > 6 years of Linux experience, and no problems caused by this :)
> 
> Just compilation errors, like vo fbdev as you can see :)

No, that error has nothing to do with glibc. The exact same error
would happen if glibc had been compiled against the new 2.6 test
kernel. At first glance, it appears to me to be a bug in the 2.6
version of fb.h -- it's including another kernel header without
checking #ifdef __KERNEL__.

> You can't deny this fact: this is a sympthom of the fault of your
> logic :)

No, Gabu is correct about kernel headers/libc.

> And how said that kernel should be at /usr/src/linux?

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

> I have several kernels, and not even /usr/src/linux directory. So where
> can you symlink then? :) And if you're using multiple kernels, let's say
> a 2.4.x for daily work, and 2.6.0-test2 for testing? You should relink
> /usr/include/linux each time you boot into a new kernel? ;-)

If 2.6 headers weren't broken then it should definitely be 2.6.
Building against newer kernel headers should not cause problems when
running on an older kernel, except some ioctl's might not be available
(and thus they will gracefully fail). On the other hand, building
against old kernel headers will prevent using new features (like
v4l2).

> The correct policy: for "normal" user space programs you should include
> from /usr/include/linux which is kernel headers glibc was compiled against,
> and specify the ABSOLUTE path of withing kernel source if you depend on
> a certain kernel, the desired method is to add the following path to
> eg -I switch of gcc:

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
libc that doesn't grow exponentially with each release, e.g. uclibc).
In any case, if there is such a problem, it's a bug in glibc.

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
enlighten us by showing us the particular struct
definitions/prototypes/whatever that conflict...

> > > because you should compile both of glibc and kernel if any of them is
> > > replaced
> > Recompile glibc on kernel upgrade. Muhaha. :)
> 
> Recompile IF you do that stupid symlinking!

No, you would have to recompile glibc to use new kernel features (like
fb after upgrading from linux 2.0 to 2.2) if you insist on keeping the
kernel headers 'in sync' with your glibc. This is dumb.

> Gabu, as you know I like you :), but please do not argue, I think I know
> much more about kernel than you :) It's a pointless argument, and you try to
> show your truth with jokes and hypes, but not actual technical facts ...

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

Rich