[Vm-dev] Raspberry Pi build issues with old friend 'gl.h'

[Eliot Miranda]

Hi Tim,

    there's a pattern for selectively not building a plugin that I implemented for the processor simulator plugins do that they are only built if one has build the support libraries.  I wonder if (no, I expect that) the pattern can be extended to the B3DAcceleratorPlugin.  Take a look at the makefiles for the processor plugins and see if there's some variable that specifies prerequisites.  I'd look myself but I'm away from my build machine right now.

_,,,^..^,,,_ (phone)

> On Feb 21, 2018, at 4:53 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> After successfully getting the git repository downloaded and initialised with updateSCCSVersions I tried the build. It was more than a bit confusing to work out what was happening but it seems that there is (again, oh joy) an issue with gl.h
> 
> The config log found that my Pi lacks GL/gl.h and correctly appears to mark it as missing. The actual build nonetheless tries and fails to build B3DAcceleratorPlugin, which turns out to break the rest of the build for some reason. I feel sure that it didn't used to completely stop the process, but maybe I'm forgetting. 
> 
> I know we've had related problems with gl.h plenty of times before and I can only imagine that the setup used for the auto build process must have a suitable installed development package. If that's so, I'd appreciate knowing what package that might be. I always load up  i2c-tools, netatalk, libnss-mdns, libx11-dev, uuid-dev, libcairo2-dev, libpango1.0-dev, autoconf, libasound2-dev & libssl-dev when I put together a new Raspbian disk; I used to include mesa-common-dev but stopped that some time ago since it seemed to cause the vm to not find the X11 display stuff.
> 
> Somewhere in the config/build cycle I'd say the evidence suggests that a better connection could be made between the test and the decision to build the B3DAccelleratorPlugin - but that's something I know squat about. The relevant section in the configure script seems to be around line 27495 and involve things like `ac_cv_lib_GL_glIsEnabled=no`. I had always thought that the config test were meant to prevent the later build from trying to make components that couldn't be made successfully?
> 
> For now, simply removing the problem plugin from the plugins.ext list lets me make a working vm but this isn't a happy state for us to be in. We've had several pushes at re-writing the config stuff in the past and I really thought some progress had been made.  Is anybody an aficionado of unix config systems? We have the example of the interpreter vm tree using the (apparently) improved cmake (?) system to prove that it can be a little less nasty.
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Fractured Idiom:- MONAGE A TROIS - I am three years old
> 
>