CommonProblems
The LOFAR build environment uses the GNU autoconf/automake/libtool suite. Like most powerful tools out there, when it fails, it can fail in quite mysterious ways. I will try to document the various modes of failure on this page, and please feel free to add your own. The page is divided into rough sections, so if you add your own material, please try to follow the structure.
Usually, when you've got build errors in a specific package, you can save some time by doing a rebuild just in that package. But sometimes all else fails and you need a truly new start. Try it as follows:
$ cd Timba
$ cd build/gnu3_debug
$ make distclean
$ cd ../..
$ svn up # full update from subversion
$ ./bootstrap
$ rm `find . -name "*.la"` # cleans out libtool files, just in case...
$ cd build/gnu3_debug
$ ../../lofarconf && make -j10
The extra rm command is needed because make distclean, for mysterious reasons of its own, does not always clean out libtool files, which can sometimes get contaminated with incorrect dependencies, etc.
If your build fails after you've just updated everything from CVS, this may be due to one of three highly popular causes: Someone's checked in broken code : bad bad someone X-( . However, you can always use cvs to roll everything back to a known working version:
$ cd LOFAR/Timba
$ cvs up -D "10 May"
Alternatively, if there's a known stable version tagged with a tagname (we do this every now and then), you can check it out with cvs up -rtagname. Please see UsingCvs and man cvs for details.
You've got some broken code in your local tree.
:
E.g., you've just updated some package you were using, and your modifications are no longer compatible. Run cvs -n up to see what still needs to be updated w.r.t. CVS (the -n option ensures that nothing actually gets updated, only reported). Any files marked with "M" are modified in your local tree, and may be culprits.
You've got an old sticky tag!
:
Whenever you update things with cvs up -D or cvs up -r, cvs will set a "sticky tag" on all affected files and directories in your local tree. If someone then commits some changes to cvs and you do another cvs up expecting to check out these changes, nothing actually gets updated because the sticky tag keeps you stuck to the version specified with -D or -r! (And if you have set sticky tags on only a subset of the tree, it gets even more confusing...) You need to do a cvs up with the '-A' option (as in the intructions above) to clear all sticky tags.
This:
configure: WARNING: Could not find libtool in /home/lofar/stable/LOFAR/Timba/Common/build/gnu_opt
configure: error: Probably package Timba/Common has not been configured yet
is a very misleading error. What it actually means is that LCS/Common has not been configured. You need to do this to keep the build system happy... see ../ActualBuild for details.
This:
/home/.../LOFAR/Timba/MeqServer/configure: line 9175: lofar_DEBUG_OPTIMIZE: command not found
/home/.../LOFAR/Timba/MeqServer/configure: line 9176: syntax error near unexpected token `1'
/home/.../LOFAR/Timba/MeqServer/configure: line 9176: `lofar_BLITZ(1)'
make[1]: *** [config.status] Error 2
make[1]: Leaving directory `/home/twillis/LOFAR/Timba/MeqServer/build/gnu3_debug'
make: *** [gnu3_debug.variant_build] Error 2
tends to happen when autoconf_share and/or some package's configure.in file has changed. It means you need to go back and do a ./bootstrap again (globally in Timba, or perhaps within the affected package only) to bring things back into sync.
Automake and libtool can get terminally confused after an upgrade, etc. You should go into the affected package, clean out the build directory, and then bootstrap all over again:
$ cd LOFAR/Timba/Package
$ rm -fr build/gnu3_debug/*
$ ./bootstrap
$ cd build/gnu3_debug
$ ../../lofarconf && make -j10
If the problem is early on in the build, you may be better off just doing a straight fresh rebuild as outlined above.
This message usually appears if you make a syntax error in a Makefile.am. To find the exact location of the error, you need to look at the indicated line of the offending makefile, usually located somewhere like build/gnu3_debug/src/Makefile. The makefile is generated automatically by automake; however, just correcting the original Makefile.am is sometimes not sufficient. You may need to bootstrap the affected package again.
dlopen and openpty: : On an older system with a 2.4 kernel, I saw the following messages when building MeqServer:
/usr/local/lib/libpython2.3.a(dynload_shlib.o)(.text+0x192): In function `_PyImport_GetDynLoadFunc':
Python/dynload_shlib.c:129: undefined reference to `dlopen'
/usr/local/lib/libpython2.3.a(dynload_shlib.o)(.text+0x1cf):Python/dynload_shlib.c:137: undefined reference to `dlsym'
/usr/local/lib/libpython2.3.a(dynload_shlib.o)(.text+0x1df):Python/dynload_shlib.c:132: undefined reference to `dlerror'
/usr/local/lib/libpython2.3.a(posixmodule.o)(.text+0x1ff6): In function `posix_openpty':
/tmp/Modules/posixmodule.c:2820: undefined reference to `openpty'
/usr/local/lib/libpython2.3.a(posixmodule.o)(.text+0x2052): In function `posix_forkpty':
/tmp/Modules/posixmodule.c:2878: undefined reference to `forkpty'
The cure for this is to explicitly link in libdl and libutil. The correct way to do this is to edit your variants.hostname file, and add "-ldl -lutil" to the "--with-ldflags" option of the gnu3.compiler.conf setting.
NB: there is a known problem with new (>=1.5.20) versions of of libtool, which shows up in a way similar to that described below. Try rebuilding (from make distclean -- the build environment is notorious for making private copies of libtool) with an older version, i.e.. 1.5.6. We are currently working on this problem.
{{{ ImportError: cannot import name octopython: cannot resolve symbol ImportError: cannot import name py_app_launcher}}}
usually indicate that your shared libraries (packages OCTOPython and PyApps) have not been built properly.