Looking further at config.log and the output from configure, there are a few further improvements that could be made to make the build better.
Add –enable-jit option, although this causes a warning claiming to be a missing LLVM include file, but closer examination of the config.log file shows actually is caused by failure to use the required ‘–std=gnu++11’ option to the compiler. Including this option, however, causes other build failures. For the moment I will keep this option but not worry about the warning it generates.
Add –with-openssl option. This opened a can of worms. Starting with disabling the GUI, with a claim that it couldn’t find the OpenGL library. This was actually not the case, instead the OpenGL library was missing a TLS function (it remains unclear to me so far why a general purpose graphics library should use encryption, but such are the mysteries of open source software). Adding the –enable-glx-tls option to the mesa build should resolve that. Only, it doesn’t.
Turns out that what I am building is 64-bit software, so the libraries land in /usr/local/lib64 rather than the search path I had given of /usr/local/lib. Confusingly there appears to be duplicates of a number of libraries between the two directories and their versions are not necessarily in sync. Most of this is because I have built things, but I don’t think I’m responsible for all of it. I don’t yet understand how Linux handles thunking around between 32 and 64 bit. I’m guessing 64-bit software can easily thunk down to use 32-bit libraries, but that it is either difficult or impossible to go the other way. From what I remember, also, dependency handling for different versions is a bit of a mess, meaning it would be possible to have both 32-bit and 64-bit versions of the same library loaded by the same program and there would be no guarantee that they would be of the same code version and configuration. This could lead to some entertaining bugs where doing the same thing in slightly different ways within a program might lead to different behaviours. But that is not what I am considering here, I just want to build it at the moment.
Then using static data in 64-bit libraries causes a build error unless you are building with the -fPIC option – which was not the case for fltk, adding the –enable-shared option to the fltk build resolves that.
Examining the build configuration shows OSMesa and Sndfile are missing.
OSMesa can be enabled as part of the mesa build, but again there is a dependency on TLS support, which is not fulfilled – looking into this a bit more there are again two versions of libOSMesa.so in my system, this time I know it to be my fault as one is in /usr/lib, the other /usr/local/lib. The first step to resolving this is to ensure that there is only one version of libGL.so on the library path, then rebuilding mesa.
And I have set up a new Jenkins project for libSndFile, this in turn depends upon FLAC.