Neil Hopcroft

A digital misfit

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.


Dolfin success

It has taken a bit of wrangling but I’ve finally gotten dolfin to build. The final set of adjustments I have made to the build are:
mv dolfin/la/PETScKrylovSolver.cpp dolfin/la/PETScKrylovSolver.cpp.orig
sed 's/^.*KSPSetNull/\/\/ Line removed to fix build problem/' < dolfin/la/PETScKrylovSolver.cpp.orig > dolfin/la/PETScKrylovSolver.cpp
mv dolfin/la/CholmodCholeskySolver.cpp dolfin/la/CholmodCholeskySolver.cpp.orig
echo '#include "SuiteSparse_config.h"' > dolfin/la/CholmodCholeskySolver.cpp
cat dolfin/la/CholmodCholeskySolver.cpp.orig >> dolfin/la/CholmodCholeskySolver.cpp
mv dolfin/la/UmfpackLUSolver.cpp dolfin/la/UmfpackLUSolver.cpp.orig
echo '#include "SuiteSparse_config.h"' > dolfin/la/UmfpackLUSolver.cpp
cat dolfin/la/UmfpackLUSolver.cpp.orig >> dolfin/la/UmfpackLUSolver.cpp

This gets the package building with a few optional dependencies missing:

  • — (**) SLEPC
  • — (**) SLEPC4PY
  • — (**) TRILINOS
  • — (**) PASTIX
  • — (**) SCOTCH
  • — (**) HDF5

SLEPc and SLEPc4Py don’t make any sense since those are building and installing apparently correctly.
Trilinos doesn’t clone correctly in the context of the automated build, but I can clone it if I do it manually. However, even when I do that it doesn’t build.
Pastix and Scotch are both built and installed, but not found.
HDF5 is built without parallel support.


Octave build break: SuiteSparse version

The recent update to the latest SuiteSparse has caused a build error, undefined references to SuiteSparse_realloc, SuiteSparse_free, SuiteSparse_time, SuiteSparse_calloc, SuiteSparse_config and SuiteSparse_malloc. This appears to be because they have moved to a new library, libsuitesparse_config.a and the octave dependencies haven’t yet been updated. Indeed, I suspect there are a number of other projects which will suffer a similar break.
After a little hacking around I have added a build hack to include the library in the dependency list whenever cxsparse is used. This isn’t the right solution, but should get the build working for the moment.
Of course, the frustrating thing here is that the SuiteSparse upgrade doesn’t resolve the error I was seeing in the dolfin build. That is still giving me the same undefined symbol errors. Again, I have made a hack to get around them, but they need a proper solution. What I have done is add the SuiteSparse_config.h header to the files causing errors, CholmodCholeskySolver.cpp and UmfpackLUSolver.cpp
This, however, shows there might be another problem with the build – there is some overlap between SuiteSparse_config.h and UFConfig.h, suggesting there could be a version clash between different suitesparse versions. (which, indeed, may be the cause of the original error in the octave build)
For the moment I will just worry about getting a build working again, and trust that the developers of suitesparse have done a reasonable job of maintaining compatibility.


fem-fenics octave package

As I mentioned before the fem-fenics package requires its own whole set of dependencies, a number of which are available on the fenics website. The octave package is an octave interface onto the fenics project, so to test it we need to install fenics.

  • To install the octave fem-fenics package we first need to build the code in the fem-fenics/src directory. This causes a configure error
    • “error: dolfin required to install Fem-fenics Package”.
    • build dolfin package

  • Building the dolfin package:
    • “Unable to find the requested Boost libraries.”
    • sudo yum install boost-devel

    • “Could not find a configuration file for package UFC that is compatible with requested version 1.6.0.”
    • build ffc package, which includes the now-deprecated UFC package

    • “Could NOT find Eigen3”
    • build eigen package

    • “Could NOT find PythonLibs”
    • I changed python symlink to point to 2.7.9 while python2 symlink remained linked to 2.6.9.

    • “ImportError: No module named ufl.log”
    • build ufl package

    • “ImportError: No module named FIAT.functional”
    • build fiat package

    • “ImportError: No module named instant”
    • build instant package

    • “CholmodCholeskySolver.cpp:97:17: error: ‘SuiteSparse_long’ was not declared in this scope”
    • Update SuiteSparse to the latest version

  • Building the ffc package:
    • “Python 2.7 or higher required, please upgrade.”
    • Switched symlinks to 2.7

    • “Unable to find SWIG version 3.0.3 or higher.”
    • build the swig package

  • Building the swig package:
    • “yodl2man: Command not found”
    • Install yodl, which requires icmake to build

  • Building the eigen3 package:
  • …there are a number of optional packages, which may be required for other packages, so we’ll need a rebuild once everything else is building

  • Building the ufl package:
  • …builds without error

  • Building the fiat package:
  • …builds without error

  • Building the instant package:
  • …builds without error

  • Building the SuiteSparse package:
    • “/usr/bin/ld: cannot find -lopenblas”
    • Install the latest OpenBLAS package


Build errors in the stk octave package

I’ve taken a look at the stk package following comments from Julien Bect on the maintainers mailing list. The Octave code I have comes from http://www.octave.org/hg/octave and stk code from http://hg.code.sf.net/p/octave/stk, my build is configured to poll for SCM changes and rebuild when a change happens. It’s running on a small AWS instance, so builds can take quite a long time.

The octave package build performs the same steps for all packages:

  • update from source control
  • uninstall package
  • adjust build files
  • build c++ code
  • build package
  • install package
  • test package

It seems like this sequence isn’t appropriate for stk. The build error I see is during the build package stage, where it complains “package is missing file: DESCRIPTION”.
Looking more closely there are some instructions in the README file describing the installation process, run skt_init.m in octave. Running this the package installs, but it doesn’t follow the conventions of the other packages and doesn’t show in the list of installed packages.
The stk_init.m file has a setting STK_OCTAVE_PACKAGE = false; which appears to be a mechanism to set the code to install as an uninstallable package, but that isn’t working for me.


Response from the octave maintainers mailing list

There were a number of comments to my initial mail to the maintainers mail list.

  • “reviving the fixed-point arithmetic package would be great. It’s gotten badly bit-rotten, and is of interest to people working with certain digital signal processing hardware.”
  • “Having regularly updated reports on the status of Octave packages would be great. Even better would be to have some code coverage statistics associated to the unit tests, but we’re not there yet.”
  • “In your post “Octave Packages CI build dependencies “, you report “Build error” for stk, but you don’t provide the version of stk (nor the version of Octave) that you have tested. Could you please tell me more about this “Build error”? A release was made very recently (2.3.0), could you try it and see if the build error is still there?”
  • “Neat. Would you like your blog to be syndicated at http://planet.octave.org ?”
  • “Btw, we already have code coverage for core Octave. It’s part of our Hydra builds: http://hydra.nixos.org/jobset/gnu/octave-default#tabs-jobs”…”But it covers C++ code, not m-files, right ?”

Which boils down to a few useful things for me to do:

  • Get all the package tests working and reporting results in a sensible way
    • Reporting any problems I find along the way to the current maintainers where there are any
  • Get some .m file coverage tests working for the packages
  • Pick up the fixed package and bring it up to releasable standard

octave build break – interp1q

My octave CI build has failed with this error:

make[2]: Entering directory `/usr/share/tomcat7/.jenkins/workspace/octave/scripts’
make[2]: *** No rule to make target `deprecated/interp1q.m’, needed by `all-am’. Stop.

This appears to be caused by

Changeset 19526:ccef60b2a058 by Rik:
maint: Remove functions deprecated in 3.8.

* scripts/deprecated/module.mk: Remove deprecated scripts from build system.

* scripts/deprecated/default_save_options.m,
scripts/deprecated/gen_doc_cache.m, scripts/deprecated/interp1q.m,
scripts/deprecated/isequalwithequalnans.m,
scripts/deprecated/java_convert_matrix.m, scripts/deprecated/java_debug.m,
scripts/deprecated/java_invoke.m, scripts/deprecated/java_new.m,
scripts/deprecated/java_unsigned_conversion.m, scripts/deprecated/javafields.m,
scripts/deprecated/javamethods.m,
scripts/deprecated/re_read_readline_init_file.m,
scripts/deprecated/read_readline_init_file.m,
scripts/deprecated/saving_history.m:
Remove scripts deprecated in 3.8 ahead of 4.2 release.

Which appears to remove a number of deprecated scripts, but maybe not completely.

It looks like it should be fixed by this change:

Changeset 19527:cd5ae0f080e8 by Rik:
maint: Remove interp1q deprecated in 3.8.

* scripts/deprecated/module.mk: Remove interp1q.m from build system.
The file was modified scripts/deprecated/module.mk (diff)