Neil Hopcroft

A digital misfit

Build break in mesa – build 98

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

automake configuration

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

Build break in fltk – build 32

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

Octave build break – build 298

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

Octave build break: SuiteSparse version – revisited

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

Octave package test results revisited

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

Dolfin success

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

Octave build break: SuiteSparse version

Tags:

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.


Categories: Octave, Open Source.

/ Leave a comment

fem-fenics octave package

Tags:

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


Categories: Octave, Open Source.

/ 2 Comments

Build errors in the stk octave package

Tags:

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.


Categories: Octave, Open Source.

/ 2 Comments

Previous

Next