The of-ngspice project fails with
/usr/bin/ld: cannot find -lngspice
collect2: error: ld returned 1 exit status
A search for libngspice fails to turn anything up – so perhaps we’re not building the library? Checking the ngspice project output there is no mention of a library there. However, there is a ‘–with-ngshared’ option to configure, which seems like what we want.
Fixed in build 17.
The first failure in the restructured octave forge packages is fem-fenics, with:
uBLAS_factory.cc: In member function ‘virtual octave_value uBLAS_factory::matrix(const dolfin::Matrix&) const’:
uBLAS_factory.cc:36:12: error: ‘const class dolfin::Matrix’ has no member named ‘data’
aa = A.data ();
^
make: *** [uBLAS_factory.o] Error 1
There is some discussion about this error, and some of the issues around it, which although it makes some sense seems like it hasn’t actually been fixed in the code. The fix appears to be removing the uBLAS backend, but that seems like a chunk of work that will come along sometime. In the meantime I just need the build to complete, so I have added a patch:
sed 's/A.data ..;/NULL; return retval;/' uBLAS_factory.cc.orig > uBLAS_factory.cc
which replaces the unfound value with NULL and returns without attempting to use it. This is not ideal but should be enough to get the build to move on.
Next the build was missing the dolfin package during the install stage, adding the correct PKG_CONFIG_PATH resolves this.
Then libQtCore was not found, adding /usr/local/Trolltech/Qt-4.8.6/lib/ to the LD_LIBRARY_PATH resolves this.
Now I am seeing
/fem-fenics-0.0.4/x86_64-unknown-linux-gnu-api-v50+/Function.oct: undefined symbol: _ZNK5boost3mpi12communicatorcvP19ompi_communicator_tEv
error: called from ‘doc_cache_create>create_cache’ in file /usr/share/tomcat7/.jenkins/workspace/octave/scripts/help/doc_cache_create.m near line 106, column 18
More work needed – this looks like it might be “boost::mpi::communicator::operator ompi_communicator_t*() const” missing from my boost_mpi library.
Following on from some of my previous planning, I have now created a bunch of new of-* packages. Where the name of package is taken from the git or mercurial repository name, using the of-* naming convention I have set up a page in Jenkins to show only the octave forge packages making it easier to see what is going on with them.
This leads me to successful builds with the majority of packages while a few errors remain:
I will take a closer look at these errors over the next few weeks.
During this move to the new structure I have lost the tests for the installed packages – I’m not quite sure what to do about this yet, I was thinking of setting up a new Jenkins project to run just the tests from the old octave-packages project, but again that seems like it doesn’t really reflect the reality of how changes happen in the code. More thinking needed.
Following a discussion on the maintainers mailing list about some recent problems with sourceforge, the Octave Forge packages are moving away from the sourceforge version control system. I have, for a while, been thinking about restructuring my octave-packages project. The current structure has two layers, one for the svn code from sourceforge, then a second with a number of mercurial projects. From a CI build point of view, only the svn repository is checked for changes, although whenever a build is made the mercurial packages are updated.
According to the octave forge webpage, the svn repository still exists, although it is now mostly a place for unmaintained code. There is also now some new packages using git.
Now I’m thinking about switching over to a bunch of projects, one for each octave forge package, as well as keeping the first layer of the current set up for the svn packages. This would make the whole thing a bit more manageable as the current build takes hours, nothing is properly cleaned and everything gets rebuilt whether it is needed or not. One of the big problems is that the octave-packages project has a dependency on dolfin, which gets a lot of updates, meaning there are lots of rebuilds requested. Moving to individual packages would mean that could be cut down to a single package being rebuilt for every dolfin build.
The octave forge packages also have their own dependency map, which could then be reflected in the build structure.
It is going to take quite a lot of setting up to get the new projects arranged and building, but it should make for clearer builds. What is going to get more complicated, though, is collecting the test results, since that is currently done at the end of the octave-packages build. What I could do would be to keep the current test code and move that to a project that runs daily.
This break started with
CMake Error at CMakeLists.txt:889 (message):
Generation of form files failed:sh: ffc: command not found
…in build 202, but then a change was made to update the dependencies, requiring ffc version 1.7.0. However the ffc version on the master branch is still 1.6.0, a little searching around shows that the ‘next’ branch has advanced its version number to 1.7.0. Rebuilding using ‘next’ branch instead gives: “OSError: Unable to find SWIG version 3.0.3 or higher.”
Adding SWIG to the CI builds resolves this and gets dolfin building again.
Fixed in build 214.
Phew, that was a lot of build breaks – that is what happens when you stop paying attention and let the code rot set in. They’re all fixed now except obd android (recent change missing some files) and qhull (cannot reach git server). Still, I’m back on top of things now.
During these fixes I have made a few environmental changes, updating tool versions and various other configurations, each of which has potential to disrupt builds of other projects. Where I’ve known about the implications of these changes I have made a note in my recent posts and built those things that I am aware of needing checking. But I’m getting nervous that I’ve done a lot of changes without rebuilding everything.
So, I’m going to rebuild everything. This gives me a chance to test out my build_all project, upon which everything should have a dependency, either directly or indirectly. Before I do this, though, I am going to wait for the server to be quiescent.
Following some recent changes to the Octave build process to eliminate recursive use of make my CI build has started failing with this error:
CXX libgui/src/libgui_src_libgui_src_la-moc-dialog.lo
libgui/src/moc-dialog.cc:12:24: fatal error: src/dialog.h: No such file or directory
#include “src/dialog.h”
^
compilation terminated.
make[2]: *** [libgui/src/libgui_src_libgui_src_la-moc-dialog.lo] Error 1
Which appears to be a problem with directories during qt pre-processing, but I don’t know what I can do about it. Revisiting the octave project configuration I have disabled the documentation – I have re-enabled that in the hope that there is a hidden dependency causing my build error.
With the documentation enabled I now get this error:
CXX libgui/qterminal/libqterminal/libgui_qterminal_libqterminal_la-moc-QTerminal.lo
libgui/qterminal/libqterminal/moc-QTerminal.cc:12:46: fatal error: qterminal/libqterminal/QTerminal.h: No such file or directory
#include “qterminal/libqterminal/QTerminal.h”
^
compilation terminated.
make[2]: *** [libgui/qterminal/libqterminal/libgui_qterminal_libqterminal_la-moc-QTerminal.lo] Error 1
So there is now a dependency upon qterminal, which in turn has a dependency upon qtermwidget.
Although the above doesn’t contain the missing header. It turns out that there is another qterminal, from google code, which does contain the missing QTerminal.h file.
This qterminal doesn’t publish the header files to the /usr/… tree, so I have added creation of a symbolic link to the qterminal project.
Except that isn’t actually what the problem is! A bit of looking at the file system shows there is actually a qterminal contained within octave/libgui and that is the one it is expecting to use, and the problem is that the change to non-recursive make has broken that because the include directories are now relative to a different place. Adding CXXFLAGS=-Ilibgui to the environment before calling ./configure fixes this.
But it appears that the documentation is still broken for me – this might be a similar relative directories change – I had been copying groff.enc to doc/interpreter but now it cannot find it while building things in doc/interpreter. Copying it to the project root instead fixes this.
This fix also fixes the build break in octave-packages, which was caused by the missing octave program output from this build.
Build fixed in 378.
There was a build break in the freeglut build:
[ 38%] Built target freeglut
Linking C executable bin/CallbackMaker
lib/libglut.so.3.10.0: undefined reference to `sball_initialized’
collect2: error: ld returned 1 exit status
make[2]: *** [bin/CallbackMaker] Error 1
make[1]: *** [CMakeFiles/CallbackMaker.dir/all] Error 2
There were a significant number of changes included in build 7 as it was originally configured without SCM polling, but that was enabled and build 7 was the catchup build. A little investigation shows that the error originates from linkage of one of the demos. Since we don’t need those, and we don’t really care about freeglut except that we use it for eigen -> dolfin -> octave-packages, we can disable the demos by calling ‘cmake -DFREEGLUT_BUILD_DEMOS=OFF ..’.
Turning off the demos doesn’t really help, we are now getting a complaint about cmake version, I have 2.8.12 installed while 3.0.0 is required. To fix this I’ll need to install the new version of cmake, but that, in turn, will require rebuilds of the projects that use cmake.
The update to cmake 3 resolves the build error, and triggers builds of eigen and dolfin. I have now manually requested builds for qhull and vtk to ensure the change doesn’t break their builds.
The qhull build remains broken, but because it has a version control problem rather than anything related to cmake. vtk builds successfully.
Freeglut fixed in build 14.
The mesa build broke with this error message:
checking for INTEL… no
configure: error: Package requirements (libdrm_intel >= 2.4.61) were not met:Requested ‘libdrm_intel >= 2.4.61’ but version of libdrm_intel is 2.4.60
This was caused by this change:
Commit a025e539e430b7bbfae9b786bd79d0d608f1acf8 by emil.l.velikov
i965: bump libdrm requirement to 2.4.61 and drop in-tree workaround
To satisfy this dependency I have added libdrm to the build server, this resolves the dependency problem but leaves two undefined values, I915_PARAM_REVISION and I915_PARAM_CMD_PARSER_VERSION. Adding CFLAGS=”-DI915_PARAM_REVISION -DI915_PARAM_CMD_PARSER_VERSION” to the ./configure line of the build resolves these values to the point of completing the build, although I don’t know if it will cause problems because of incorrect values.
Break resolved in build 115.
I have noticed a few projects failing during autogen or automake stages, with errors that don’t make much sense, things like missing gettext and libtool, although they are both installed:
configure.ac: not using Gettext
configure.ac: not using Libtool
A bit of hunting around the internet suggests that automake looks in the same directory as itself for those supporting tools, and I had updated automake to version 1.15, as required by another project. While doing this I had installed it in /usr/local/bin rather than /usr/bin, meaning it lost gettext and libtool as the local version was found earlier on my path. I have now removed the local version and re-installed my updated 1.15 version in /usr/bin.
The projects affected by this configuration error are:
However, this still doesn’t resolve the problem – the automatic build is still missing gettext while running the same build from command line completes the configure stage.
Looking more closely at librsvg, I see that it is missing calls to libtoolize and gettextize. Adding those allows the build to continue a little further, but it is still giving an error: “error: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL”. Copying introspection.m4 to m4/ resolves this problem and allows the build to run to completion.
But this doesn’t seem like the proper solution to this problem – it is a hack to make it work. How to find the proper solution?
I ran the builds from a terminal where they worked as expected. So perhaps the problem is an environmental issue? Checking the path between the Jenkins build and terminal shows some differences. Indeed, using the Jenkins path in the terminal gives the same errors as I see in the CI build. Aha! It turns out that Jenkins is picking up the wrong version of aclocal, removing aclocal from /usr/local/bin fixes this problem, now everything is in /usr/bin and all of the above projects are now building.
I am a bit nervous about doing these kinds of sweeping configuration changes, so now I feel like I need to rebuild everything, just to make sure that I haven’t broken other things with this change.