The build of this project fails to find mkoctfile, in the src/Makefile there is a comment “# assumptions to make if not using ./configure script” after which it defines MKOCTFILE to $(HOME)/usr/bin/mkoctfile
Setting MKOCTFILE on the make command line can fix this, but only with make invoked directly – the octave pkg function calls make as part of its installation process.
An alternative to this is to make a link to mkoctfile in $HOME of the tomcat user.
Fixed in build 24.
Neil Hopcroft
A digital misfit
Fixing of-fl-core build
The fl-core package is giving this error:
fl_compose.cc: In function ‘int get_available_cpus()’:
fl_compose.cc:757:19: error: ‘_SC_NPROCESSORS_ONLN’ was not declared in this scope
return sysconf( _SC_NPROCESSORS_ONLN);
^
fl_compose.cc:757:39: error: ‘sysconf’ was not declared in this scope
return sysconf( _SC_NPROCESSORS_ONLN);
^
make: *** [fl_compose.oct] Error 1
A quick search of the octave source code shows a potential alternative, _SC_NPROCESSORS_CONF, if _SC_NPROCESSORS_ONLN is not defined. But it also says “This works on glibc, Mac OS X 10.5, FreeBSD, AIX, OSF/1, Solaris, Cygwin, Haiku” for both CONF and ONLN.
For the moment I have replaced the call to sysconf with a hard-coded ‘1’, representing a single core. Not an ideal solution but it should work for my current purposes.
Fixed in build 23.
Fixing of-ngspice
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.
Fixing of-fem-fenics build
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.
The clarity of a well ordered mind^wbuild – octave forge project restructuring progress
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:
- of-fem-fenics
- of-fixed
- of-fl-core
- of-galois
- of-ltfat
- of-multi-precision
- of-ngspice
- of-odepkg
- of-optim
- of-optiminterp
- of-stk
- of-video
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.
Restructuring the CI build for Octave Forge packages
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.
Build break in dolfin – build 202
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.
Round up after build break fixes
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.
Build break in octave – build 307
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.
Build break in freeglut – build 7
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.
- dolfin
- eigen
- qhull
- vtk
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.