PiBox

This issue requires a fix within the core PiBox, not to xbmcbox.

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.

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.

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.

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.