Bug #137
closed
xbmc requires glxinfo
100%
Description
When I tried to run xbmc from the opkg installation I got an error that glxinfo was not found. glxinfo is not included in the userland tools. I'm guessing that glxinfo, which I think is in the Mesa3D packages needs to be compiled against the userland tools, which means it won't build directly out of buildroot. I've posted a question about this to the Raspberry Pi forums.
Updated by Hammel about 12 years ago
- Project changed from xbmcbox to PiBox
- Target version deleted (
Beta 1)
This issue requires a fix within the core PiBox, not to xbmcbox.
Updated by Hammel about 12 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 20
I think, but am not certain yet and based on this dicussion, that I only need to build the basic Mesa3D libraries via the X.org build in Buildroot to satisfy this issue. After that, if the ld conf is correct, then xbmc should be able to find the tools it requires.
Note that after this build, the xbmc build should be rerun so that I can assure it picks up the ARM OpgnGL libs and not the x86_64 libs from the host.
Updated by Hammel about 12 years ago
Mesa builds easily enough, but the version in Buildroot is recent enough to not include the GLU, GLUT or demos packages. These have to be added as selectable packages to be built if Mesa3D is enabled or that enable Mesa3D if selected.
I know I need the demos package to get glxinfo. I don't know if I need GLU or GLUT. I'll have to check the dependencies list for an XBMC build.
Updated by Hammel about 12 years ago
- % Done changed from 20 to 30
GLEW has a Makefile-based build that doesn't look easy (at first glance) to convert to cross compile usage. GLUT was similarly difficult.
Because I'm unclear if glew and glut are really needed, I'm going to test a rebuild of xbmc without these. I've built the rootfs with Mesa3D and GLU and then rebuilt xbmc against that new rootfs. Now it's time to load both the new rootfs and the xbmc opkg onto an SD card and try them.
Updated by Hammel about 12 years ago
- Priority changed from Immediate to Normal
- % Done changed from 30 to 50
- Severity changed from Critical to Medium
I think the problem here is that xbmc is not getting built correctly, not that we need glxinfo. Tests with ldconfig on the rpi show tools like busybox are okay, but xbmc.bin is broken. So this is probably a fix needed in xbmcbox and now here.
For now, lowering the priority of this issue until I can verify xbmc is getting built properly. Then we'll see if it really needs glxinfo.
Updated by Hammel almost 12 years ago
- Category set to 00 - Basic Build Issues
- Status changed from In Progress to Closed
- Target version set to 0.5.0 - Beta 1
- % Done changed from 50 to 100
I've cleaned up the XBMCBox build so it properly cross compiles. I think the binary is valid but it still doesn't run, possibly because of the way I've installed the Raspberry Pi firmware and/or userland tools.
To get around the glxinfo problem you have to edit the /opt/xbmc-bcm/xbmc-bin/bin/xbmc script and comment out the check for glxinfo. It's not really required in this case. However, that means I'll have to add a modified version of this script to the XBMCBox source tree and make sure it gets copied in during the build of that project.