RedHat MultiNest: failed install, issue with CMake/BLAS/LAPACK (or pthreads) - installation

I am trying to install MultiNest on my desktop running Enterprise Red Hat 6.6 (Santiago). I downloaded the necessary package (MultiNest_v3.9_CMake.tar.gz), and followed the installation instructions:
cd MultiNest/build
cmake ..
Although BLAS and LAPACK are installed, I get the following errors:
CMake Error at /usr/share/cmake/Modules/FindBLAS.cmake:594 (message):
A required library with BLAS API not found. Please specify library
location.
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindLAPACK.cmake:142 (find_package)
src/CMakeLists.txt:31 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
See also "/home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeOutput.log".
See also "/home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeError.log".
Any suggestions?
The output "CmakeError.log" is below, and seems to indicate that the problem instead involves something called "pthreads".
Determining if the pthread_create exist failed with the following output:
Change Dir: /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/gmake" "cmTryCompileExec4203479411/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec4203479411.dir/build.make CMakeFiles/cmTryCompileExec4203479411.dir/build
gmake[1]: Entering directory /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec4203479411.dir/CheckSymbolExists.c.o
/usr/local/Ureka/python/bin/gcc -o CMakeFiles/cmTryCompileExec4203479411.dir/CheckSymbolExists.c.o -c /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTryCompileExec4203479411
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec4203479411.dir/link.txt --verbose=1
/usr/local/Ureka/python/bin/gcc CMakeFiles/cmTryCompileExec4203479411.dir/CheckSymbolExists.c.o -o cmTryCompileExec4203479411 -rdynamic
CMakeFiles/cmTryCompileExec4203479411.dir/CheckSymbolExists.c.o: In functionmain':
CheckSymbolExists.c:(.text+0xc): undefined reference to pthread_create'
collect2: ld returned 1 exit status
gmake[1]: Leaving directory/home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp'
gmake[1]: * [cmTryCompileExec4203479411] Error 1
gmake: * [cmTryCompileExec4203479411/fast] Error 2
File /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
include
int main(int argc, char** argv)
{
(void)argv;
ifndef pthread_create
return ((int*)(&pthread_create))[argc];
else
(void)argc;
return 0;
endif
}
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/gmake" "cmTryCompileExec3959414027/fast"
/usr/bin/gmake -f CMakeFiles/cmTryCompileExec3959414027.dir/build.make CMakeFiles/cmTryCompileExec3959414027.dir/build
gmake[1]: Entering directory /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp'
/usr/local/bin/cmake -E cmake_progress_report /home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec3959414027.dir/CheckFunctionExists.c.o
/usr/local/Ureka/python/bin/gcc -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec3959414027.dir/CheckFunctionExists.c.o -c /usr/local/share/cmake-3.1/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec3959414027
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3959414027.dir/link.txt --verbose=1
/usr/local/Ureka/python/bin/gcc -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTryCompileExec3959414027.dir/CheckFunctionExists.c.o -o cmTryCompileExec3959414027 -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: ld returned 1 exit status
gmake[1]: Leaving directory/home/ianc/Downloads/MultiNest/build/CMakeFiles/CMakeTmp'
gmake[1]: * [cmTryCompileExec3959414027] Error 1
gmake: * [cmTryCompileExec3959414027/fast] Error 2

Install these libraries and their devel versions for the build headers
libblas{3,-dev} liblapack{3,-dev} libatlas{3-base,-dev} cmake build-essential gfortran
You can also try installing compat packages.

The error above indicates that the POSIX threading library, libpthreads, cannot be found on your system. This error originates from your system-provided FindLAPACK.cmake script rather than from something in the MultiNest package.
I don't know the specific library which provides this on RedHat, but you should be able to check using yum provides pthread. After this you can install it using yum install M where M is whatever library provides libpthread from the previous command.

Related

gcc/gfortran 11 cannot find headers/libraries in default locations

After upgrading python 3.8.6 to 3.9.10 using homebrew, my Cython extensions no longer without explicitly adding /usr/local/include (for my Intel MacBook) or /opt/homebrew/include to the include_dirs of my extension.
My setup.py.in:
import os, sys
from numpy.distutils.core import setup, Extension
from Cython.Build import cythonize
link_arguments = []
extra_include_dirs = []
if (sys.platform == 'darwin'):
link_arguments.append("-Wl,-rpath")
link_arguments.append("-Wl,#loader_path/")
if os.path.exists('/opt/homebrew/'):
extra_include_dirs.append("/opt/homebrew/include/")
else:
extra_include_dirs.append("/usr/local/include/")
else:
link_arguments.append("-Wl,-rpath=${CMAKE_SOURCE_DIR}/lib/")
pynwp_extension = Extension(
name="pynwp",
sources=["${CMAKE_CURRENT_SOURCE_DIR}/lambert.f90", "${CMAKE_CURRENT_SOURCE_DIR}/pynwp.f90", "${CMAKE_CURRENT_SOURCE_DIR}/readAtmosphereGen.f90", "${CMAKE_CURRENT_SOURCE_DIR}/ptogrot.f", "${CMAKE_CURRENT_SOURCE_DIR}/bilin1.f", "${CMAKE_CURRENT_SOURCE_DIR}/fl2pres_f.f","${CMAKE_CURRENT_SOURCE_DIR}/message.c","${CMAKE_CURRENT_SOURCE_DIR}/gridWindDirCorrection.F"],
libraries=["HirlamUtils_fPIC", "eccodes_f90", "jasper"],
library_dirs=["${PROJECT_BINARY_DIR}", "${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}/src/libHirlamUtils/", "/opt/homebrew/lib/"],
extra_link_args = link_arguments,
include_dirs=["${CMAKE_SOURCE_DIR}/include", "/usr/lib64/gfortran/modules/",
"${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}"] + extra_include_dirs,
extra_f90_compile_args=["-DLINUX", "-DIS_LITTLE_ENDIAN", "-DUSEWALLTIME", "-DHAS_BLAS", "-DHAS_LAPACK", "-DGRIB32", "-DTIMING", "-DPREC32", "-fno-whole-file", "-g", "-fbounds-check"]
#compiler_directives={'language_level' : "3"}
)
setup(name="pynwp",
author="me",
author_email="me!me.com",
version="1.0.1",
description="Python wrapper for pynwp",
package_dir={"": "${CMAKE_CURRENT_SOURCE_DIR}"},
url="http://emaddc.eu",
license="MIT License",
ext_modules=[pynwp_extension]
)
In the file above, I have hardcoded the location (temporarily) of the homebrew library dir and added some functionality for the include dir based on /opt/homebrew being found. If I remove this from the file, compilation fails as eccodes.mod cannot be found, see the output when I run the command generate by python/CMake manually:
buildDebug git:(master) ✗ /opt/homebrew/bin/gfortran -Wall -g -fno-second-underscore -fPIC -O3 -funroll-loops -I<project_dir>//include -I/usr/lib64/gfortran/modules/ -I<project_dir>//buildDebug -Ibuild/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9 -I/opt/homebrew/lib/python3.9/site-packages/numpy/core/include -Ibuild/src.macosx-12-arm64-3.9/numpy/distutils/include -I/opt/homebrew/opt/python#3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c -c <project_dir>//src/pynwp/readAtmosphereGen.f90 -o build/temp.macosx-12-arm64-3.9<project_dir>//src/pynwp/readAtmosphereGen.o -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -DPREC32 -fno-whole-file -g -fbounds-check
f951: Warning: Nonexistent include directory '/usr/lib64/gfortran/modules/' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/numpy/distutils/include' [-Wmissing-include-dirs]
<project_dir>//src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
This extension is part of a larger project that is build using CMake. When running the gfortran command manually, the same errors indicating that eccodes.mod cannot be found. The file is however located on a default location on the gfortran/gcc search path:
locate eccodes.mod
/opt/homebrew/Cellar/eccodes/2.24.2/include/eccodes.mod
/opt/homebrew/include/eccodes.mod
And the search path for gfortran:
gfortran -E -Wp,-v -
#include <...> search starts here:
/opt/homebrew/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.
Another project uses gcc/ld and has a similar problem. I need to explicitly add LINK_DIRECTORIES(/opt/homebrew/lib) to CMakeList.txt in order for gcc to find the eccodes library. Without that, I get:
gcc-11: warning: this compiler does not support X86 (arch flags ignored)
ld: library not found for -leccodes
collect2: error: ld returned 1 exit status
make[2]: *** [src/smoothModeS-v51/smoothModeS-v51.x] Error 1
make[1]: *** [src/smoothModeS-v51/CMakeFiles/smoothModeS-v51.x.dir/all] Error 2
make: *** [all] Error 2
Adding the paths to CPATH and LIBRARY_PATH had no effect.
This method works but seems hard to maintain. What am I missing and what has changed that gfortran/gcc no longer search in the default paths for but libraries and headers/modules?
EDIT
Just found that the standalone executable that uses similar code as the python extension and also uses eccodes has a similar issue. If I do not include INCLUDE_DIRECTORIES(/opt/homebrew/include) in CMakeLists.txt , I get:
cd <project_dir>/buildDebug/src/collocEHS && /opt/homebrew/bin/gfortran -I<project_dir>/buildDebug -I<project_dir>/include -I<project_dir>/src/readASTERIX2 -I<project_dir>/src/geomag70_linux -I<project_dir>/src/libDTG -fallow-argument-mismatch -ffpe-trap=invalid,zero,overflow -DPREC32 -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -ffixed-line-length-none -g -fcheck=all -Wall -fcheck=bounds -O0 -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -c <project_dir>/src/pynwp/readAtmosphereGen.f90 -o CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o
<project_dir>/src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
make[2]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o] Error 1
make[1]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/all] Error 2
make: *** [all] Error 2
So I guess the problem is unrelated to python but more with gcc/gfortran (gcc version 11.2.0 (Homebrew GCC 11.2.0_3).
EDIT 2
A reboot of the laptop fixed the issue with the python extension build and setup.py requiring additional directories. For normal builds using CMake, I still require the extra INCLUDE_DIRECTORIES and LINK_DIRECTORIES order for gcc/gfortran to find libraries installed by brew in /opt/homebrew (or /usr/local for intel MacBook).
As per homebrew devs, this is desired behaviour: /opt/homebrew and /usr/local are "special" directories to be manually added in e.g., CMake projects. This is explained in my bug report on home-brew's GitHub, see https://github.com/Homebrew/homebrew-core/issues/95561.
I haven't been able to confirm this with documentation.

CalculiX installation error etime (In function `second_':)

I have been following the instructions to install CalculiX and its dependencies as best as I could from the wiki page https://github.com/precice/calculix-adapter/wiki/Installation-instructions-for-CalculiX
I have already installed all the dependencies.
In the installation when I say make I get the following error:
gfortran -fopenmp -Wall -O3 -o bin/ccx_preCICE bin/ccx_2.15.o bin/ccx_2.15.a /home/prasad/SPOOLES.2.2//spooles.a -L/usr/local/lib -lprecice -lstdc++ -L/home/prasad/yaml-cpp-yaml-cpp-0.6.2//build -lyaml-cpp /home/prasad/ARPACK//libarpack_INTEL.a -lpthread -lm -lc
/home/prasad/ARPACK//libarpack_INTEL.a(second.o): In function `second_':
second.f:(.text+0x14): undefined reference to `etime_'
collect2: error: ld returned 1 exit status
Makefile:101: recipe for target 'bin/ccx_preCICE' failed
make: *** [bin/ccx_preCICE] Error 1
I tried changing the line 24 in ARPACK/UTIL/second.f to * EXTERNAL ETIME, but I am still getting the same error.
Can anyone tell me how to fix it?
Thank you in advance for the help.
Edit line 24 in ARPACK/UTIL/second.f
Append * to get
* EXTERNAL ETIME
If you get this error when you are building the adapter for CalculiX, go to ARPACK
make lib
Go back to the calculiX-adapter-master directory or the directory from where you were building CalculiX and its adapter
make clean
make
For detailed guide please check preCICE wiki for CalculiX adapter

Install nullfs on Debian

I am using a java program. It automatically creates log files in a directory, but I am doing that myself a different way with tee. I cannot find an easy way to disable the logs, so I am resorting to using nullfs.
I cloned it with
git clone https://github.com/xrgtn/nullfs.git
and I ran
make nul1fs
as instructed. It terminates within a second, with the following output:
cc "-lfuse" nul1fs.c -o nul1fs
nul1fs.c:13:18: fatal error: fuse.h: No such file or directory
compilation terminated.
make: *** [nul1fs] Error 1
I tried apt-get source fuse and copying fuse.h into the nullfs directory, but nothing changed.
I have FUSE installed. I'm running Debian wheezy x86_64.
You need the development package of FUSE, which contains the fuse.h you're missing. Do a apt-get install libfuse-dev and it should work.
Copying the header file in the source directory did not work, because in nul1fs.c you'll notice that fuse.h is included with angle brackets. This means, the header file will be searched in the system-wide include paths. That usually means /usr/include.
Note that you then may run into this error:
$ make nul1fs
cc "-lfuse" nul1fs.c -o nul1fs
/tmp/ccbt0X7c.o: In function `main':
nul1fs.c:(.text+0x3c3): undefined reference to `fuse_main_real'
collect2: error: ld returned 1 exit status
make: *** [nul1fs] Error 1
It's a documented bug with a workaround: put the linker flags after the file lists. I.e. compile nul1fs with:
cc nul1fs.c -o nul1fs -lfuse
and not with make nul1fs, which boils down to
cc -lfuse nul1fs.c -o nul1fs

bigloo scheme "make test" fails for pthreads

I am trying to build from the bigloo scheme's latest source 3.8a on a Linux Mint 12 (lisa), which is Ubuntu 11 (Oneric) derivative:
Here is my "configure":
./configure --enable-pthread --enable-fthread --enable-ssl --enable-sqlite --enable-web --enable-multimedia --enable-mail --enable-calendar --enable-pkgcomp --enable-pkglib --enable-gstreamer --enable-text --enable-srfi1 --enable-srfi27 --enable-crypto --enable-openpgp --enable-phone --enable-alsa --enable-mpg123 --enable-csv --jvm=yes
** Configuration summary **
Release features:
release number.............. 3.8a
supported backends.......... native:yes JVM:yes
default backend............. native
additional APIs............. pthread fthread sqlite web multimedia mail calendar pkgcomp pkglib text srfi1 srfi27 packrat crypto openpgp phone mpg123 csv
native threads support...... yes
openssl support............. no
sqlite support.............. sqltiny + sqlite
dynamic libraries support... yes
Bee configuration:
bee support................. partial
emacs....................... emacs
emacs brand................. emacs23
Implementation details:
tuning...................... standard
cc.......................... gcc
gc.......................... custom (bigloogc-3.8a, v731)
Java version................ 1.3
bignum support.............. gmp (5.0.1)
Directories where Bigloo will be installed:
binaries.................... /usr/local/bin
libraries................... /usr/local/lib
files directory............. bigloo/3.8a
standard zip................ /usr/local/lib/bigloo/3.8a
standard dll................ /usr/local/lib/bigloo/3.8a
manual pages................ /usr/local/man/man1
info documentation.......... /usr/local/info
lisp files..................
temporary build dir......... /tmp
The "make" succeeds; however "make test" fails for pthread
*** pthread **********
make[2]: Entering directory `/home/liew/Downloads/bigloo3.8a/api/pthread/recette'
/home/liew/Downloads/bigloo3.8a/bin/bigloo -c -call/cc -O3 -fcfa-arithmetic -q recette.scm -o recette.o
/home/liew/Downloads/bigloo3.8a/bin/bigloo -O3 -fcfa-arithmetic -q recette.o -o recette
/usr/bin/ld: recette: hidden symbol `pthread_atfork' in /usr/lib/i386-linux-gnu/libpthread_nonshared.a(pthread_atfork.oS) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [recette] Error 1
make[2]: Leaving directory `/home/liew/Downloads/bigloo3.8a/api/pthread/recette'
make[1]: *** [c-test] Error 1
make[1]: Leaving directory `/home/liew/Downloads/bigloo3.8a'
make: *** [test] Error 2
According to this excellent post about this pthread issue, we need to rearrange the command line parameters while linking pthread library. However, I was unable to find the required Makefile code - probably because it relies on the Makefile default that links the library in a certain way.
Any help will be appreciated.
The problem is probably fixed in newer versions of bigloo.

CMake/GCC "unrecognized option" on Mac OS X

I'm trying to create a project as a shared library in OS X using CMake 2.8 and gcc 4.6 (from macports). When CMake gets to the point of linking my library into a .dylib, I get the following error from gcc:
g++ -dynamiclib -headerpad_max_install_names -o libmycoollibrary.dylib etc...
g++: error: unrecognized option '-h'
make[2]: *** [libnrtCore.dylib] Error 1
make[1]: *** [CMakeFiles/nrtCore.dir/all] Error 2
make: *** [all] Error 2
This -headerpad_max_install_names seems to be the problem, but I've never seen it before. Does anyone know how to either get CMake to not include this option, or to get GCC to accept this option?
You can re-build cmake to fix this -- it's apparently generating code for the XCode / Darwin version of g++ (a special version of 4.2), which accepts a number of non-standard linker flags.
Just change the Modules/Platform/Darwin*.cmake files and re-build. The culprit lines look like this:
SET(CMAKE_CXX_LINK_FLAGS "-Wl,-search_paths_first -headerpad_max_install_names")

Resources