Re: [suse-amd64] MPlayer 1.0pre5 - Compile Error `CONFIG_X86_L1_CACHE_SHIFT'
On Thursday 29 July 2004 4:33 am, you wrote:
I had no problems... Try easing back on the functions your compiling in...
Humm, that zings right over my head. I have to admit my ignorance here. As far as I know, I'm not 'compiling in' anything other than what the package itself calls for. I did a... ./configure --enable-libsuffix=64 make Is there something I should be doing to 'ease back on the functions'? Scott
On Thu, 2004-07-29 at 16:47, Scott Leighton wrote:
Having a problem compiling the latest version of MPlayer (I did get an earlier version compiled with no problems).
Has anyone gotten the 64 bit version of this to compile, or does anyone have a suggestion on how to resolve the error: `CONFIG_X86_L1_CACHE_SHIFT' undeclared here (not in a function)
Scott
helphand@helphand:~/MPlayer-1.0pre5> make make -C libvo make[1]: Entering directory `/home/helphand/MPlayer-1.0pre5/libvo' cc -c -I../libvo -I../../libvo -I/usr/X11/include -O4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I.. -I../osdep -I/usr/include/freetype2 -I/usr/X11/include -I/usr/include/directfb -DMPG12PLAY -o vo_fbdev.o vo_fbdev.c In file included from /usr/include/asm/pda.h:4, from /usr/include/asm-x86_64/thread_info.h:14, from /usr/include/asm/thread_info.h:4, from /usr/include/linux/thread_info.h:21, from ../osdep/kerneltwosix.h:4, from vo_fbdev.c:21: /usr/include/asm-x86_64/pda.h:26: error: `CONFIG_X86_L1_CACHE_SHIFT' undeclared here (not in a function) /usr/include/asm-x86_64/pda.h:26: error: requested alignment is not a constant In file included from /usr/include/asm/processor.h:4, from /usr/include/linux/prefetch.h:13, from /usr/include/linux/list.h:7, from ../osdep/kerneltwosix.h:5, from vo_fbdev.c:21: /usr/include/asm-x86_64/processor.h:229: error: `CONFIG_X86_L1_CACHE_SHIFT' undeclared here (not in a function) /usr/include/asm-x86_64/processor.h:229: error: requested alignment is not a constant make[1]: *** [vo_fbdev.o] Error 1 make[1]: Leaving directory `/home/helphand/MPlayer-1.0pre5/libvo' make: *** [libvo/libvo.a] Error 2 helphand@helphand:~/MPlayer-1.0pre5> -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.95-default x86_64
-- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.95-default x86_64
Scott Leighton wrote:
On Thursday 29 July 2004 4:33 am, you wrote:
I had no problems... Try easing back on the functions your compiling in...
Humm, that zings right over my head. I have to admit my ignorance here. As far as I know, I'm not 'compiling in' anything other than what the package itself calls for. I did a...
./configure --enable-libsuffix=64 make
Is there something I should be doing to 'ease back on the functions'?
Scott
<STUFF DELETED> It does not know about --enable-libsuffix I built mine with "./configure --with-x11libdir=/usr/X11R6/lib64 --libdir=/usr/lib64 --prefix=/usr --disable-fbdev --enable-gui" and used checkinstall to generate the rpm. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====
On Friday 30 July 2004 4:17 pm, Sid Boyce wrote:
Scott Leighton wrote:
On Thursday 29 July 2004 4:33 am, you wrote:
I had no problems... Try easing back on the functions your compiling in...
Humm, that zings right over my head. I have to admit my ignorance here. As far as I know, I'm not 'compiling in' anything other than what the package itself calls for. I did a...
./configure --enable-libsuffix=64 make
Is there something I should be doing to 'ease back on the functions'?
Scott
<STUFF DELETED> It does not know about --enable-libsuffix I built mine with "./configure --with-x11libdir=/usr/X11R6/lib64 --libdir=/usr/lib64 --prefix=/usr --disable-fbdev --enable-gui" and used checkinstall to generate the rpm. Regards Sid.
--
Thanks! That --disable-fbdev did the trick, it compiles clean now. I appreciate the pointer! Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.95-default x86_64
On Friday 30 July 2004 6:44 pm, Scott Leighton wrote:
On Friday 30 July 2004 4:17 pm, Sid Boyce wrote:
Scott Leighton wrote:
On Thursday 29 July 2004 4:33 am, you wrote:
I had no problems... Try easing back on the functions your compiling in...
Humm, that zings right over my head. I have to admit my ignorance here. As far as I know, I'm not 'compiling in' anything other than what the package itself calls for. I did a...
./configure --enable-libsuffix=64 make
Is there something I should be doing to 'ease back on the functions'?
Scott
<STUFF DELETED> It does not know about --enable-libsuffix I built mine with "./configure --with-x11libdir=/usr/X11R6/lib64 --libdir=/usr/lib64 --prefix=/usr --disable-fbdev --enable-gui" and used checkinstall to generate the rpm. Regards Sid.
--
Thanks! That --disable-fbdev did the trick, it compiles clean now. I appreciate the pointer!
Scott
OK, more information regarding this compile issue on the amd64. The mplayer user list had a post that referenced this exact issue and suggested that the real problem is that the SuSE distro has /usr/include/linux set up incorrectly. I quote... "I've seen this one lately. The problem was using a custom kernel, but leaving the vendor supplied kernel headers in place." "/usr/include/linux should be a symlink to /usr/src/linux/include/linux" SuSE has /usr/include/linux as a real directory that contains numerous include files dated March 2004 on my 9.1 Pro setup. The /usr/src/linux/include/linux directory also exists, but it contains numerous include files with dates AFTER March 2004. Now, to be clear here, I am NOT using a custom kernel. I am using only what SuSE updates my system to with YOU. To test the mplayer theory, I renamed /usr/include/linux to /usr/include/linux2 and then created a symlink from /usr/include/linux to /usr/src/linux/include/linux then tried compiling mplayer with the following; ./configure --with-x11libdir=/usr/X11R6/lib64 --libdir=/usr/lib64 --enable-gui make It compiled clean, no issues, unlike the problem when compiling using /usr/include/linux. I then installed with checkinstall and tested gmplayer, worked fine. So, my big question here is is the guy on the mplayer list right? Has SuSE messed up the location of the correct include files for the kernel? Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.108-default x86_64
fredag 15 oktober 2004 06:32 skrev Scott Leighton:
So, my big question here is is the guy on the mplayer list right? Has SuSE messed up the location of the correct include files for the kernel?
I'm not a kernel hacker, of course ... but from what I've gathered so far, is that programs that require kernel headers should be acquiring those through /lib/modules/<kernel-version>/build/include ... but SuSE has botched that job, I usually have to fix that link when I build Nvidia driver.
On Fri, Oct 15, 2004 at 01:57:39PM +0200, ?rn Hansen wrote:
fredag 15 oktober 2004 06:32 skrev Scott Leighton:
So, my big question here is is the guy on the mplayer list right? Has SuSE messed up the location of the correct include files for the kernel?
I'm not a kernel hacker, of course ... but from what I've gathered so far, is that programs that require kernel headers should be acquiring those through /lib/modules/<kernel-version>/build/include ... but SuSE has botched that job, I usually have to fix that link when I build Nvidia driver.
That's intentional. The kernel includes need to be configured in the same way as the running kernel (or for all kernels if you want to distribute a module in binary form), and that needs some manual steps. For simple kernel modules it sometimes doesn't make a difference, but you will run into problems with more complex ones. See /usr/src/linux/README.SUSE for details. -Andi
On Friday 15 October 2004 5:27 am, Andi Kleen wrote:
On Fri, Oct 15, 2004 at 01:57:39PM +0200, ?rn Hansen wrote:
fredag 15 oktober 2004 06:32 skrev Scott Leighton:
So, my big question here is is the guy on the mplayer list right? Has SuSE messed up the location of the correct include files for the kernel?
I'm not a kernel hacker, of course ... but from what I've gathered so far, is that programs that require kernel headers should be acquiring those through /lib/modules/<kernel-version>/build/include ... but SuSE has botched that job, I usually have to fix that link when I build Nvidia driver.
That's intentional. The kernel includes need to be configured in the same way as the running kernel (or for all kernels if you want to distribute a module in binary form), and that needs some manual steps. For simple kernel modules it sometimes doesn't make a difference, but you will run into problems with more complex ones.
See /usr/src/linux/README.SUSE for details.
-Andi
OK, you both have confused me even more than I was already confused <g>. First point, the README Andi references states the following: "In the installed system, the kernel-source package installs files in the following directories: * /usr/src/linux-$VERSION-$RELEASE/ The kernel sources. * /usr/src/linux A symbolic link to /usr/src/linux-$VERSION-$RELEASE. " So, why is it that /usr/src/linux on my box is not a symbolic link, it's a real directory that contains a bunch of header files dated March 2004. Second point, and keep in mind that I am basically clueless here, the original question had to do with compiling MPlayer from source since a pre-built binary RPM for 64 bit doesn't seem to be available. So, the problem resolves around compiling an application so it can be installed and run. Has nothing to do with compiling kernels or kernel modules, just an application. When I try to compile the MPlayer package using the /usr/src/linux setup that SuSE put on my machine, it fails with the Compile Error `CONFIG_X86_L1_CACHE_SHIFT' error _unless_ I include a configuration switch to exclude framebuffer support, e.g., --disable-fbdev. Changing that /usr/src/linux directory to a symbolic link to /usr/src/linux/include/linux (which is also a real directory with a bunch of header files with various dates, some as recent as Aug 25th) results in a compile that is error free without using the --disable-fbdev setting. So, what does this have to do with /lib/module/.....? I'm totally confused and I don't think my question has been answered as to whether or not there's a problem with two sets of header files and no symbolic link. Sorry for being dense, but I'm just not getting it.... Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.108-default x86_64
* /usr/src/linux-$VERSION-$RELEASE/
The kernel sources.
* /usr/src/linux
A symbolic link to /usr/src/linux-$VERSION-$RELEASE. "
So, why is it that /usr/src/linux on my box is not a symbolic link, it's a real directory that contains a bunch of header files dated March 2004.
I don't know. Must be a non standard installation.
Second point, and keep in mind that I am basically clueless here, the original question had to do with compiling MPlayer from source since a pre-built binary RPM for 64 bit doesn't seem to be available. So, the problem resolves around compiling an application so it can be installed and run. Has nothing to do with compiling kernels or kernel modules, just an application.
When I try to compile the MPlayer package using the /usr/src/linux setup that SuSE put on my machine, it fails with the Compile Error `CONFIG_X86_L1_CACHE_SHIFT' error _unless_ I include a configuration switch to exclude framebuffer support, e.g., --disable-fbdev.
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. But it sounds like your installation is quite messed up. Maybe it is just some missing some files somewhere.
So, what does this have to do with /lib/module/.....? I'm totally confused and I don't think my question has been answered as to whether or not there's a problem with two sets of header files and no symbolic link.
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. -Andi
On Friday 15 October 2004 6:30 pm, Andi Kleen wrote:
* /usr/src/linux-$VERSION-$RELEASE/
The kernel sources.
* /usr/src/linux
A symbolic link to /usr/src/linux-$VERSION-$RELEASE. "
So, why is it that /usr/src/linux on my box is not a symbolic link, it's a real directory that contains a bunch of header files dated March 2004.
I don't know. Must be a non standard installation.
I'm honestly not smart enough to create a non standard installation. Everything on the machine is stock SuSE, I've built several apps like MPlayer by compiling sources and installing with checkinstall, but that is the full extent of my ability. So, from where I sit, if it's non-standard, then SuSE made it that way, not me.
Second point, and keep in mind that I am basically clueless here, the original question had to do with compiling MPlayer from source since a pre-built binary RPM for 64 bit doesn't seem to be available. So, the problem resolves around compiling an application so it can be installed and run. Has nothing to do with compiling kernels or kernel modules, just an application.
When I try to compile the MPlayer package using the /usr/src/linux setup that SuSE put on my machine, it fails with the Compile Error `CONFIG_X86_L1_CACHE_SHIFT' error _unless_ I include a configuration switch to exclude framebuffer support, e.g., --disable-fbdev.
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.
But it sounds like your installation is quite messed up. Maybe it is just some missing some files somewhere.
Well, if it is, I'd sure like to know who did it/how it got that way. And I suspect I'm not the only one.... others have run into the MPlayer problem on the the list here, the solution up to now was to do the --disable-fbdev thingy, but I think that just masked over the real issue of kernel includes not being in the correct place. If someone at SuSE with official knowledge could clarify, it sure would be appreciated. Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.108-default x86_64
lördag 16 oktober 2004 03:44 skrev Scott Leighton:
Well, if it is, I'd sure like to know who did it/how it got that way. And I suspect I'm not the only one.... others have run into the MPlayer problem on the the list here, the solution up to now was to do the --disable-fbdev thingy, but I think that just masked over the real issue of kernel includes not being in the correct place.
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.
If someone at SuSE with official knowledge could clarify, it sure would be appreciated.
Second that.
Hi Guys
I eableto compile MPlayer on my AMD 64 bit Laptop disabling
the frame buffer. But now I am having another problem , though I
enable graphics mode of MPlayer & got the gmplayer binary , it is not
working. It get hagned while loading the skins.
Anirban Biswas.
On Sat, 16 Oct 2004 16:32:59 +0200, Örn Hansen
lördag 16 oktober 2004 03:44 skrev Scott Leighton:
Well, if it is, I'd sure like to know who did it/how it got that way. And I suspect I'm not the only one.... others have run into the MPlayer problem on the the list here, the solution up to now was to do the --disable-fbdev thingy, but I think that just masked over the real issue of kernel includes not being in the correct place.
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.
If someone at SuSE with official knowledge could clarify, it sure would be appreciated.
Second that.
-- If Bill Gates is the Devil then Linus Torvalds must be the Messiah.
On Sunday 17 October 2004 9:41 am, Anirban Biswas wrote:
Hi Guys
I eableto compile MPlayer on my AMD 64 bit Laptop disabling the frame buffer. But now I am having another problem , though I enable graphics mode of MPlayer & got the gmplayer binary , it is not working. It get hagned while loading the skins.
Make sure you have some skins installed, and try different ones. The skins look awful on 64 bit, mine come out with a terrible blue tint. It's a problem that, to my knowledge, has not been solved. Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.108-default x86_64
Hi Scott
You know this is the beauty of MPlayer even the GUI is not
working I can use it any way , so currently I am not giving to much
though but enjoying the DVD I bough this week end.
Anirban Biswas.
On Sun, 17 Oct 2004 09:52:29 -0700, Scott Leighton
On Sunday 17 October 2004 9:41 am, Anirban Biswas wrote:
Hi Guys
I eableto compile MPlayer on my AMD 64 bit Laptop disabling the frame buffer. But now I am having another problem , though I enable graphics mode of MPlayer & got the gmplayer binary , it is not working. It get hagned while loading the skins.
Make sure you have some skins installed, and try different ones. The skins look awful on 64 bit, mine come out with a terrible blue tint. It's a problem that, to my knowledge, has not been solved.
Scott
-- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.108-default x86_64
-- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com
-- If Bill Gates is the Devil then Linus Torvalds must be the Messiah.
lördag 16 oktober 2004 03:30 skrev Andi Kleen:
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.
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.
-Andi
participants (5)
-
Andi Kleen -
Anirban Biswas -
Scott Leighton -
Sid Boyce -
Örn Hansen