Having a smoothly working build is what we aim to provide for you. Yet, facing all those different systems, there are still situations where stuff goes wrong.
In order to help you out as good and fast as possible we implemented a build report system for support.
The report system is realized via a
support target that can be built, e.g.:
This will collect build information and create a zip file, which you can attach to any support email.
Why do you have different folder structures for debug/release builds?
By design, users/developers should be able to build a debug version of their example or even iron while having optimized MPI and dependencies. In order to ensure to have CMake find the correct builds, separate directories are employed. Moreover, while the new cmake package config file system allows to store library information for multiple configurations, different include directories are not yet natively supported. As some packages provide fortran module files (which are different for debug/release), they need to be stored at different paths using different include directories.
How do i use precompiled dependencies like in the old build system?
See the OpenCMISS central installations section.
This section is intended to be used as first place of collection for common errors and mishaps
Im getting errors from CMake claiming “You have changed variables that require your cache to be deleted [...] The following variables have changed: CMAKE_C_COMPILER=/usr/bin/gcc (or similar)*
One case where this occurs is if you try to configure an OpenCMISS build using the same compiler but different aliases/symlinks like “gcc” or “cc”, where “cc” just is the system’s default compiler pointing to e.g. “gcc”. Assume your first configure run was just cmake .., and later you’ve decided to re-configure using cmake -DTOOLCHAIN=GNU ... Now, if selecting GNU as toolchain effectively selects the same compiler, but the binary path is different, CMake (correctly) assumes you’ve got a new compiler and needs to delete the cache. The trouble comes in as the build environment (correctly) detects that your default compiler in fact was from the GNU toolchain and hence placed the builds for the external projects under the same architecture path - boom.
Solution: Run make reset in the current architecture main build directory and re-build using make.
MPI detection mismatch. Aborting.
This occurs when the automatic MPI detection/selection system fails. A known case is e.g. if you have GNU/Intel toolchains with mpich/intel mpi installed, and there is a mpigcc wrapper within the intel MPI path, but the mpich gcc wrapper is simply called mpicc.
Solution: Instead of choosing the
MPI value, specify the
Could not find a package configuration file provided by “OpenCMISS” with any of the following names / opencmiss-config.cmake is missing
Two scenarios commonly happen here:
- For sdk installations: You specified an incorrect remote directory - see OpenCMISS central installations.
installtarget was not run. This most commonly occurs if you did not build the
Solution: Run the
install target, which installs the
Then, your example / application can use that to find your opencmiss installation.
install target is a part of the
opencmiss target, we recommend building
from the start as described in Building the OpenCMISS Suite.
examplestarget stops with errors.
At the current stage, the examples repo contains all the examples from the SVN opencmiss examples repository. We are currently working on updating/repairing/removing all of them.
Solution: Invoke your build with flags to ignore intermediate errors. For
make this is achieved using the
opencmiss_key_iron_python_bindingskey test fails with
/bin/python: symbol lookup error: /usr/lib/openmpi/lib/openmpi/mca_paffinity_linux.so: undefined symbol: mca_base_param_reg_int
This is a known bug in OpenMPI implementations which have been build as shared libraries. See for example https://www.open-mpi.org/community/lists/devel/2005/09/0359.php or https://groups.google.com/forum/#!msg/hoomd-users/BBAQnzHCRhA/5RhrDddLHWEJ
Solution: Update your system/openmpi installation and try again. Otherwise, you can
- Install a statically build version of OpenMPI
- If you built OpenMPI yourself, rebuild with
- Use another MPI implementation: Specify e.g.
-DMPI=mpichat configure stage (Remember to build
reset-mpionlyand clear the build folder before, see also Building for multiple architectures/configurations)
- Have the build system build OpenMPI for you by specifying
-DSYSTEM_MPI=NO -DMPI=openmpi; see also Building for multiple architectures/configurations
- Modify your Python script: https://code.google.com/archive/p/distnumpy/issues/1