Problem in running the example

[henshs]

I have successfully built and installed RePrimAnd from the source on my Mac m2 Ventura. Then I compiled the example successfully "/<repository>/examples/minimal_tov.cc" by command g++ -lRePrimAnd -I/opt/homebrew/opt/boost/include --std=c++11 minimal_tov.cc and it generated "a.out" executable. When I tried ./a.out to run the example it gave an error

"dyld[74642]: symbol not found in flat namespace '_cblas_caxpy'
zsh: abort ./a.out"

I could not understand the root of this problem to find a way out.

[wokast]

The most probable cause is that the library was linked to different library versions than the example, likely GSL/BLAS The example compile command assumes all libraries are in standard locations. Further, if shared libraries like GSL used for building reprimand are not in the standard linker search path, but other versions are, then problems like this can result.

To diagnose, please run
ldd a.out and check that the gsl and blas libraries listed are the same version used when building reprimand, i.e. if they differ from any explicitly specified non-standard library search path or path detected by meson build system.

[henshs]

Thanks.

I tried ldd ./a.out but it did not work and gave output zsh: command not found: ldd. I have found that the equivalent tool of ldd on Mac is otool -L.

Then I tried otool -L ./a.out and it gave the following outputs

@rpath/libRePrimAnd.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

It seems that the compatibility version is different than the current version. I would be glad if a workaround could be found to test the example.

[wokast]

please run otool also on the libRePrimAnd.dylib shared library. I suspect a problem with the GSL and/or the CBLAS library dependencies. Could it be that one or both of these are installed in different versions both on your system and the conda environment? If reprimand was compiled using a library inside a non-standard location, the system might not be able to find it anymore when running a program linked to reprimand, or it might try to use the wrong version. This is a problem frequently encountered when installing software from source.

[henshs]

After I run otool on the libRePrimAnd.dylib shared library.

otool -L libRePrimAnd.dylib

The output is as follows:

libRePrimAnd.dylib:
@rpath/libRePrimAnd.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/homebrew/opt/gsl/lib/libgsl.27.dylib (compatibility version 28.0.0, current version 28.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
/opt/homebrew/opt/hdf5/lib/libhdf5.200.dylib (compatibility version 203.0.0, current version 203.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)

I suspect a problem with the GSL and/or the CBLAS library dependencies. Could it be that one or both of these are installed in different versions both on your system and the conda environment?

I checked that CBLAS library is installed only on the conda environment while GSL library is installed only on the system (using homebrew).

If reprimand was compiled using a library inside a non-standard location, the system might not be able to find it anymore when running a program linked to reprimand, or it might try to use the wrong version. This is a problem frequently encountered when installing software from source.

During installation, I did not specify library locations manually except for the Boost.

[henshs]

The problem seems related to linking error to CBLAS library.

1. I tried the "//example/minimal_tov.cc" (as there is no default output, so I added a print statement to print gravitational mass on the standard output) example with "-lcblas" flag, in particular with the command:

g++ --std=c++11 -lRePrimAnd -lcblas -I/opt/homebrew/opt/boost/include/ minimal_tov.cc

and the produced executable can be run successfully and output was shown without any issues.

2. I tried to run "//example/pwpoly_TOV.py" by command:

python3 pwpoly_TOV.py

and it showed the same CBLAS linking problem on the standard output

symbol not found in flat namespace '_cblas_caxpy'.

I was wondering if this problem could also be solved if at the runtime CBLAS library could be linked somehow like number 1.

3. While running python example on terminal does not work but the same example did work (I just copied the code "//example/pwpoly_TOV.py" and pasted on a jupyter-notebook ipykernel) surprisingly when I use Jupyter-Notebook.

[wokast]

Regarding 1) it is odd that one has to link cblas manually. reprimand does not depend directly on cblas but it depends on gsl library which in turn depends on cblas. Not sure what is going on here. It could either be that the dynamic linker behaves subtly different on MacOS (I don't have a Mac available at the moment so I will investigate later) or, more likely, that somehow your install of gsl+cblas is somehow broken. You can try installing gsl inside the conda environment as well and try building the example with that, using -L and -I options to point to the lib and include directory of gsl/cblas versions in your conda environment.

[wokast]

Regarding 2) please check that the python3 executable used to run the python example is the one from the conda environment used for building and installing reprimand.
Also, when you installed the reprimand library, did you specify the conda environment using the --prefix option to meson configure? I ask because sometimes users just install stuff globally (/usr/local on linux and whatever the MacOS equivalent is) which always creates a mess. Make sure the only reprimand library file is in the conda environment used for building it.

[wokast]

When running code on MacOs that was linked to libraries in non-system locations at build time, it may also be required to set the environment variable
DYLD_LIBRARY_PATH
to a colon-separated list of library folders. On Linux, it would be LD_LIBRARY_PATH instead.

[henshs]

Regarding 2) please check that the python3 executable used to run the python example is the one from the conda environment used for building and installing reprimand.

I suspect that system-wide "/usr/bin/python3" python3 was used for installing the python binding of reprimand.

When I run the command:

/usr/bin/python3 pwpoly_TOV.py

the error related to CBLAS disappeared and the error is now that it is unable to find reprimand module:

Traceback (most recent call last):
File "/Users/persistence/Numerical_Relativity/RePrimAnd-public/example/pwpoly_TOV.py", line 6, in <module>
import pyreprimand as pyr
ModuleNotFoundError: No module named 'pyreprimand'

Also, when you installed the reprimand library, did you specify the conda environment using the --prefix option to meson configure? I ask because sometimes users just install stuff globally (/usr/local on linux and whatever the MacOS equivalent is) which always creates a mess. Make sure the only reprimand library file is in the conda environment used for building it.

I did not specify --prefix option to customize the installation location during building the library. I understand that mixing things (libraries and executables) sometimes from system-wide and sometimes from conda environment is a mess. I would like to use and keep everything bound to conda environment.

However, I would like to know if meson will search and choose dependent libraries from conda environment first and if not found then it will search system-wide ?

After reprimand is installed, should I specify the location of reprimand library in a code or it will automatically detect similarly if it is installed system-wide ?

[henshs]

I installed all the dependencies of reprimand library (gsl,hdf5,boost) inside a conda environment and then built the reprimand library inside conda environment using --prefix option during building the library.
I had to specify the absolute path of the headers (such as unitcov.h, eos_barotr_poly.h) used in the code "/example/minimal_tov.cc" by modifying the code "/example/minimal_tov.cc".
Then, while compiling the example, I had to specify the reprimand library location (with -L option) as the library is not in standard location (e.g. /usr/local) and the include directory of boost (with -I option). The following command was used to compile the example "/example/minimal_tov.cc":

g++ -lRePrimAnd -I/Users/<computer_name>/miniconda3/envs/<conda_environment>/include -L/Users/<computer_name>/miniconda3/envs/<conda_environment>/lib --std=c++11 minimal_tov.cc

It successfully built the executable and was run successfully without any CBLAS linking separately by

export DYLD_LIBRARY_PATH=/Users/persistence/miniconda3/envs/work/lib
./a.out

Defining 'DYLD_LIBRARY_PATH' environment variable is a workaround to find 'libRePrimAnd.dylib', otherwise the following error appears when we run ./a.out

Reason: tried: '/usr/local/lib/libRePrimAnd.dylib' (no such file), '/usr/lib/libRePrimAnd.dylib' (no such file, not in dyld cache),

this error seems to me because of the non-standard installation location of reprimand library.

Also, python binding works properly without any error.

[wokast]

I had to specify the absolute path of the headers (such as unitcov.h, eos_barotr_poly.h) used in the code "/example/minimal_tov.cc" by modifying the code "/example/minimal_tov.cc".

That is never required. All compilers and build systems provide options for specifying the search path for header files. Compiling C++ code with reprimand works like for any other library: either header files and the library file are installed in standard search locations on the system or one has to specify the locations. When using g++ compiler, the options are -I for include file search path(es) and -L for library search path(es).

[wokast]

Thanks for the feedback. I am closing this ticket now since it was apparently not a problem specific to reprimand.

Installing any software package from source requires a certain amount of experience since every system is different. This is not something one can expect from the average MacOS user. I've put pre-build MacOS binaries on my todo list as ticket #33.