[MPlayer-users] Cannot compile: `CONFIG_X86_L1_CACHE_SHIFT' undeclared

[Jan Knutar]

On Sunday 21 November 2004 19:37, Attila Kinali wrote:

> > It used to be a practice there, to make /usr/include/linux a link to 
> > the kernel headers, as well as /usr/include/asm."
> 
> No, that's wrong. Both are normal directories for ages on debian.
> Actualy i never remember them being symlinks on a out of the box debian.
> (And i use debian for a damn long time)

Redhat 6.2 still had those symlinked. I think they stopped being
symlinks when linux 2.4 came.

> No, it's an "we've changed the policy again" issue.
> IMHO they have either to provide correct headers in /usr/include
> that work correctly together, or they have to make symlinks
> on boot time. Otherwise they will just break all software out there
> that is using kernel headers "the (old) official way"

There's a separate package in debian to pull in the headers. Whether
this is a good idea or not is questionable. Supposedly glibc can break
in spectacular ways if you replace the OS specific headers underneath
it with something else than it was compiled against.

> > "The official way to compile kernel modules for the current kernel 
> > is to use /lib/modules/`uname -r`/kernel/include for includes.
> > But it shouldn't be needed for any user space programs."
> 
> Wrong again. Anything that is machine dependend is defined in
> */linux resp */asm. Highly optimized programs like MPlayer need
> those to get the most out of the machine.

In 2.4 systems /lib/modules/version/build is usually a symlink to the
build directory, /usr/include/* contains the headers glibc was compiled
against.
Atleast in redhat's 2.6 based systems /lib/modules/version/build is a
real directory, not symlink anymore, containing all that's needed for
building kernel modules.