[MPlayer-users] Cannot compile: `CONFIG_X86_L1_CACHE_SHIFT' undeclared
Scott Leighton
helphand at pacbell.net
Sun Nov 21 17:00:32 CET 2004
On Sunday 21 November 2004 6:07 am, Torinthiel wrote:
> On Sun, Nov 21, 2004 at 12:22:42AM +0100, Roman Hausner wrote:
> > I am trying to compile MPlayer-1.0pre5 on my linux system (Suse 9.1,
> > 2.6.8-24-default).
> > I do a default ./configure (with or without --enable-gui)
> > I get the following compiler error:
> >
> > /usr/include/linux/prefetch.h:64: error: `CONFIG_X86_L1_CACHE_SHIFT'
> > undeclared(first use in this function)
> >
> > I have no idea what to do now ... anyone able to help me there?
> > Many thanks in advance!
>
> Probably SuSE screwed something.
> Facts are:
> /usr/include/linux/prefetch.h uses definition L1_CACHE_BYTES
> which is declared in /usr/include/asm/cache.h, but using
> CONFIG_X86_L1_CACHE_SHIFT. The latter is defined in
> /usr/include/linux/autoconf.h
> Now everything should work fine, as prefetch.h includes cache.h
> directly (and it does, as it's CONFIG_X86_L1_CACHE_SHIF that is missing.
> OTOH cache.h includes /usr/include/linux/config.h, which only includes
> autoconf.h, which should fix the problem.
> That's for plain vanilla kernel 2.4.25. I can see two possibilities.
> Either SuSE screwed something inside the kernel, so the facts I've
> stated above are not true on their machines (If you could check please)
> or someone made a mess with packages, and you've ended up with, for
> example, unmatching package versions for different parts of kernel.
> I'm blaming SuSE, because you're the second person recently reporting
> this, plain kernel works without problems and the other person also had
> SuSE.
> Torinthiel
According to a posts on the suse-e mail list,
" It's mplayer that isn't including the correct files. The files
in /usr/include belong to glibc. They're not meant to be up to date with the
kernel. If a program needs up to date, kernel specific includes ... they
should acquire them in /lib/modules/<version>/build/include ... that is the
official way to do it.
From what I can see, is that some of the developers of MPlayer are debian
users. It used to be a practice there, to make /usr/include/linux a link to
the kernel headers, as well as /usr/include/asm."
and
" I compiled the latest MPlayer as well, and had the same problem. So,
obviously MPlayer needs the latest kernel headers ... not the glibc copy, but
the real ones. But it doesn't access them in the right way, it is
expecting /usr/include/linux and /usr/include/asm-x86_64 to be a link to the
actual kernel include trees.
As far as I can see, that's an MPlayer issue."
and
"If it doesn't compile kernel modules mplayer should access kernel includes.
Actually glibc needs some, but it has its own independent copy.
Accessing kernel includes with no need would be a bug in Mplayer."
and
"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."
It's all over my head, but bottom-line, from a user perspective, it
would be nice if the mplayer and SuSe guys would agree on where
this stuff should be so it just works.
Scott
--
POPFile, the OpenSource EMail Classifier
http://popfile.sourceforge.net/
Linux 2.6.5-7.111-default x86_64
More information about the MPlayer-users
mailing list