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

[Attila Kinali]

On Sun, 21 Nov 2004 08:00:32 -0800
Scott Leighton <helphand at pacbell.net> wrote:


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

LOL
Not too long ago, using /usr/src/linux/include/linux resp 
/usr/src/linux/include/asm was the official way to do. Then the distros 
(mainly SuSE and RH) stopped to install kernel sources and told everyone
to use /usr/include/linux and /usr/include/asm and that it was the developers
fault to use /usr/src/linux in the first place. Now they are providing there
outdated versions of the kernel headers and tell again that it's the developers
fault because they are doing the wrong thing[tm].
Somewhat history feels like repeating itself.


>   From what I can see, is that some of the developers of MPlayer are debian 
> users.  

Don't tell that Arpi, according to him most developers hate Debian.

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

>   As far as I can see, that's an MPlayer issue."

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"

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

lol
Any programm that uses fbdev needs to access the kernel headers.
There is no way around it.

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

>From a developer point of view it would be nice if the distros wouldnt change
their policies too often. If possible not at all. Because
a damn lot of programs are run on very old versions of those distros
on old machines. Guessing what's now the right thing to do and where to
get what include file is impossible. Especialy as in this case it
wouldnt be too hard to provide backwards compatibilty with a 
small init script.

And yes, you might quote me on this.
And no, i'm not going to every distros ML to flame them, that's the users job.
And remember, it's MPlayer, not Mplayer.

			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu