Neil Hopcroft

A digital misfit

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.


Build break in mesa – build 98

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.


automake configuration

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:

  • librsvg
  • libxcb
  • pango

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.


Build break in fltk – build 32

The FLTK build has broken with this error:

Compiling flstring.c…
/usr/lib/gcc/x86_64-amazon-linux/4.8.2/../../../../lib64/crt1.o: In function `_start’:
(.text+0x20): undefined reference to `main’
collect2: error: ld returned 1 exit status
make[1]: *** [flstring.o] Error 1

I don’t see anything in either of the two changes introduced in this build to cause this error, which suggests it might have been introduced by a change to automake version, or some other environmental change.
Reading the README for the project suggests that rather than using ‘./autogen.sh’ the first step should be ‘make makeinclude’ followed by ‘./configure’ – build configuration changed to reflect this.
The change to ‘make makeinclude’ didn’t fix this problem, but I noticed it wasn’t picking up the freetype2 package from pkgconfig, adding freetype2.pc to the PKG_CONFIG_PATH solves this problem and the build is now working again.


Octave build break – build 298

The Octave build has broken during “make check” because of a missing file: test/test/fntest.m
The most likely candidate for causing this problem is changeset 20308:bacaec9b5535

eliminate recursive make invocation in test directory tree
* test/module.mk: New file created from test/Makefile.am, test/bug-35448/module.mk, test/bug-36025/module.mk, test/bug-38236/module.mk, test/bug-38691/module.mk, test/bug-44940/module.mk, test/class-concat/module.mk, test/classdef/module.mk, test/classes/module.mk, test/ctor-vs-method/module.mk, test/fcn-handle-derived-resolution/module.mk, and test/nest/module.mk.
* test/Makefile.am, test/bug-35448/module.mk, test/bug-36025/module.mk, test/bug-38236/module.mk, test/bug-38691/module.mk, test/bug-44940/module.mk, test/class-concat/module.mk, test/classdef/module.mk, test/classes/module.mk, test/ctor-vs-method/module.mk, test/fcn-handle-derived-resolution/module.mk, test/nest/module.mk: Delete.
* configure.ac (AC_OUTPUT): Don’t generate test/Makefile.
* Makefile.am: Include test/module.mk.
* build-aux/common.mk, test/build-bc-overload-tests.sh: Adapt to changes in Makefile structure.

I have made a crude patch in build 304 for the Makefile which has taken a copy of the Makefile as currently created and manually edited to remove the extra test/ in the check-local target. This patch is fragile, in that it will clobber any changes to the build in stages “make check” and later. A better way would be to patch using a regex to adjust Makefile.in, but it works for the moment.
This change makes the readability of the test results worse, but the results appear more-or-less the same, there is one extra test passing now that was failing before.


Octave build break: SuiteSparse version – revisited

So it seems like my fix for the SuiteSparse build break only partially fixes the problem. It does get octave building again, but it is now complaining about a couple of missing libraries, cholmod and umfpack, which I think should be included in SuiteSparse.
I have used the autoconf-er for SuiteSparse build to make it a bit easier to understand, that in itself was a little difficult to get working – I had renamed my SuiteSparse .tgz file to include the version number in the name (which the downloaded version does not). This lead to the script attempting, and failing, to download a new copy. Once I got this set back to the original name I asked it to build distfiles for all of the SuiteSparse packages, but it seems like some were missed, including the two listed above.
Asking the autoconf-er to make just the cholmod package complains about t_cholmod_gpu.c missing from SuiteSparse/CHOLMOD/Supernodal, but the file is in SuiteSparse/CHOLMOD/GPU. Copying the file to Supernodal would make the build work, but we need to do this a different way since the script deletes and unpacks a fresh version of the .tgz file. Putting it in the addons/ directory means it gets copied to the SuiteSparse/ tree fixes this problem.
This allows the umfpack package to build, since that was failing due to missing dependency on cholmod.
Once these packages were built new builds for dolfin and octave find the cholmod and umfpack libraries.


Octave package test results revisited

Following on from my previous exploration of octave package test results, I have updated the test scripts to better find functions and capture the results from their tests.
What it does now:

  • Get description of all packages
  • For each package
    • Reset counts for run, pass, xfail and skipped
    • Load package
    • For each interface category (=provides)
      • For each function in the category
        • Test the test runs
          • If the test succeeds, run it again and get and record the run, pass, xfail and skip numbers
          • If the test fails, record it as no test
    • Record the total run, pass, xfail and skip for the package
  • Write out the results at the end of the tests

I have set the build to generate tables of the test results. These aren’t pretty at the moment and could use some tidying up, not least because I haven’t gone through all of the packages and made sure they are building correctly.