Raspberry Pi build issues with old friend 'gl.h'
Locked
Raspberry Pi build issues with old friend 'gl.h'
 
|
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; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- MONAGE A TROIS - I am three years old |
Re: Raspberry Pi build issues with old friend 'gl.h'
|
|
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Fractured Idiom:- MONAGE A TROIS - I am three years old > > |
Re: Raspberry Pi build issues with old friend 'gl.h'
|
|
> On 22-02-2018, at 8:38 AM, Eliot Miranda <[hidden email]> wrote: > > > 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. It looks to me (and that is very tentative, given the complete lack of understanding of this very strange syntax) that b3dacceleratorplugin is testing a value that ought to provide the appropriate signal ---------- rm -f B3DAcceleratorPlugin.sub B3DAcceleratorPlugin.lib if test "${have_gl}" != "yes"; then echo "$as_me:$LINENO: result: ******** disabling ${plugin}" >&5 echo "${ECHO_T}******** disabling ${plugin}" >&6 disabled_plugins="${disabled_plugins} ${plugin}" fi --------------- Looking at all the usages of have_gl in platforms/unix/config/configure suggests to me that it isn't getting set to "no" in the area of configure that seems to look at whether the gl.h stuff is present. Clearly if something has gone wrong in that setting then the plugin is going to try to build inappropriately. OK, a hack stuck in there to echo the not-cancelling branch of the section at configure line 28192 shows that it deliberately doesn't cancel the plugin. Beyond that it just gets too confusing... I still have that question for whomever set up the Pi that does the autobuilds - what packages are you loading into Raspbian? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Moves his lips to pretend he's reading. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |