[Vm-dev] Raspbian build problem with libGL & X11

[tim Rowledge]

I’ve been having ‘fun’ for the last week or so building VMs for Raspbian (the Debian derived default SO for Raspberry Pi) relating to openGL & X11. I’m very confused about what the blazes is going on. Even explainign the problem is difficult!

For the last year or thereabouts I’ve been building the stack vm on my Pi and aside from the occasional screwup in our code it’s been no particular problem. The autoblech stuff regularly drives us nuts, of course, but that’s why tty is working on a CMake replacement. 

Recently though I had to give a colleague in Cambridge instructions on building the VM so he could integrate some new bitblt improvements for ARM machines and at that point all hell broke loose. He simply couldn’t get a finished vm that would just run - the X11 display driver wouldn’t admit to being abel to do its job.
Eventually we were able to show that doing a 
`LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libGL.so.1`
before running the vm would get past that. We also worked out that building *without* the mesa-common-dev package installed on the pi would make a vm with no such issue. That was extremely weird since I’ve had that package on my Pi pretty much forever. 

I noted eventually that the load-these-package list the Doug has been using did not include mesa-common-dev and made up an SD card with a fresh Raspbian and his list - no problem, except without the opengl stuff  there is no B3D plugin made. Add the mesa-common package and BOOM, non-working vm.
And in fact it turned out no B3D in my older builds either, which lead to much trawling through the  config.logs etc. It looks as though the make/config wasn’t finding the GL/gl.h header, which was (so far as I can tell from a clueless reading of the log) then leaving all that part out and thus making a working X11 driver. This morning I’ve updated the mesa-common-dev package on my main PI and now it makes a non-working-X11 vm, just as Ben was getting.

For extra fun, the log now shows that it finds GL/gl.h ok but not the damn library - which seems to be what leads to the faulty X11 driver and probably explains whey manually preloading the library (which is, of course right where it should be or I couldn’t load it) makes things ok.

The relevant lookig part of the log is-
configure:26931: checking GL/gl.h presence
configure:26941: gcc  -E  conftest.c
configure:26947: $? = 0
configure:26967: result: yes
configure:27002: checking for GL/gl.h
configure:27009: result: yes
configure:27024: checking for glIsEnabled in -lGL
configure:27054: gcc  -o conftest  -g -O3 -DNDEBUG -DDEBUGVM=0 -DNO_VM_PROFILE=1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DLSB_FIRST=1  -Wl,-z,now conftest.c -lGL  -lXext  -lSM -lICE   -ldl -lpthread -lm -lnsl -lpthread -luuid -lX11 >&5
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
configure:27060: $? = 1

And as a further check I removed mesa-common-dev and the vm runs without complaint about X11. THe log reports
configure:26886: checking GL/gl.h usability
configure:26898: gcc  -c  -g -O3 -DNDEBUG -DDEBUGVM=0 -DNO_VM_PROFILE=1 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DLSB_FIRST=1  conftest.c >&5
conftest.c:108:19: fatal error: GL/gl.h: No such file or directory

I’d be interested to know if other unix builds have a similar problem, or ideas on how to fix the problem or whatever. The lack of B3D plugins on the Pi si not a big issue right now but it would be nice to know what is actually going wrong.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: DST: Deadlock System Tables