Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEST module generated from NESTML fails to build on macOS when NEST is installed from conda-forge #2497

Closed
pnbabu opened this issue Oct 10, 2022 · 11 comments
Assignees
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: High Should be handled next stale Automatic marker for inactivity, please have another look here T: Bug Wrong statements in the code or documentation

Comments

@pnbabu
Copy link
Contributor

pnbabu commented Oct 10, 2022

Describe the bug
After installing NEST through conda-forge and installing NESTML via pip in the same conda environment, the generated NEST module from NESTML fails to compile on macOS with the following error:

clang: error: unsupported argument 'libomp' to option 'fopenmp='
make[2]: *** [CMakeFiles/nestmlmodule_lib.dir/nestmlmodule.o] Error 1
make[1]: *** [CMakeFiles/nestmlmodule_lib.dir/all] Error 2
make: *** [all] Error 2

To Reproduce
Steps to reproduce the behavior: https://nestml.readthedocs.io/en/latest/installation.html#anaconda-installation

conda create --name nestml_conda
conda activate nestml_conda
conda install -c conda-forge nest-simulator ipython cxx-compiler pyqt wxpython
pip install nestml --upgrade

The C++ path and the $PYTHONPATH are updated as mentioned in the above link. Then running the below command gives the compilation error.

nestml --input_path models/neurons/iaf_psc_exp.nestml --target_path target_iaf --logging_level INFO

Desktop/Environment (please complete the following information):

  • OS: macOS Monterey 12.6
  • Python-Version: Python 3.10
  • NEST-Version: 3.3
  • Installation: NEST installed through conda-forge

Additional context
I suspect the error is because $HOME/miniconda3/envs/nestml_conda/lib/libomp.dylib is not linked during the compilation. The library is also not listed under $HOME/miniconda3/envs/nestml_conda/bin/nest-config --libs. Although, manually adding it to the nest-config file doesn't resolve the error.

@heplesser heplesser added T: Bug Wrong statements in the code or documentation S: High Should be handled next I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) labels Oct 10, 2022
@heplesser
Copy link
Contributor

The problem is that nest-config --libs from the conda-forge build returns ... -fopenmp=libomp ..., while it should contain ... -Xclang -fopenmp .... If NEST 3.3 is built locally with clang, this works out. There are some other problems with the libs provide, which have been fixed by #2468 (not available via conda yet).

@steffengraber Is it possible to get the output from the cmake run for the conda builds? Maybe that can help to find out why we get the wrong flags.

@steffengraber
Copy link
Contributor

@heplesser
Copy link
Contributor

Should disappear with wheel-based installation.

@github-actions
Copy link

Issue automatically marked stale!

@github-actions github-actions bot added the stale Automatic marker for inactivity, please have another look here label Jan 25, 2023
@steffengraber
Copy link
Contributor

steffengraber commented Jan 30, 2023

I hope the problem will be solved with the conda package for NEST 3.4.

@github-actions github-actions bot removed the stale Automatic marker for inactivity, please have another look here label Jan 30, 2023
@terhorstd
Copy link
Contributor

Did the 3.4_rc1 solve this?

@steffengraber
Copy link
Contributor

It is hard for me to test this in macOS. With the new version, the compiler is added to the run environment and the path inside nest-config is overwritten. This should fix the problem, also in macOS.

@nicolossus
Copy link
Member

I did a conda installation of 3.4_rc1 on macOS, and the NESTML model still fails to compile with the same error:

clang: error: unsupported argument 'libomp' to option 'fopenmp='
make[2]: *** [CMakeFiles/nestmlmodule_module.dir/build.make:76: CMakeFiles/nestmlmodule_module.dir/nestmlmodule.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:112: CMakeFiles/nestmlmodule_module.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

However, if I change -fopenmp=libomp to -Xclang -fopenmp under both --cflags and --libs in the nest-config file, the NESTML model compiles successfully.

The NESTML documentation on Anaconda installation (https://nestml.readthedocs.io/en/latest/installation.html#anaconda-installation) already says one has to:

Edit nest-config and correct the entry under --compiler with the output returned by which c++

Perhaps a temporary workaround could be for the documentation to instruct macOS users to also replace -fopenmp=libomp with -Xclang -fopenmp in the nest-config.

Steps to reproduce:

Download 3.4_rc1 feedstock build conda_artifacts_20230213.5.1_osx_64_python3.10.____cpython and unpack the file and the archive directory within (I also renamed the archive directory of this particular file to build_artifacts).

Create conda environment and install:

conda create -n nestml_conda python=3.10
conda install -c conda-forge c-compiler compilers cxx-compiler make cmake zlib boost cython gsl libtool matplotlib-base readline ipython scipy statsmodels openssh pyqt wxpython
conda install --use-local build_artifacts/osx-64/nest-simulator-3.4_rc1-py310h69b982f_0.conda
pip install nestml --upgrade

Then replace --compiler entry in ~/opt/anaconda3/envs/nestml_conda/bin/nest-config with output from which c++ and -fopenmp=libomp to -Xclang -fopenmp under --cflags and --libs.

Finally, compile the NESTML model from the NESTML source directory:

$ nestml --input_path models/neurons/iaf_psc_exp.nestml --target_path target_iaf --logging_level INFO

@github-actions
Copy link

Issue automatically marked stale!

@github-actions github-actions bot added the stale Automatic marker for inactivity, please have another look here label Apr 17, 2023
@steffengraber
Copy link
Contributor

@pnbabu Can the issue be closed?

@pnbabu
Copy link
Contributor Author

pnbabu commented Aug 15, 2023

@steffengraber Yes, it can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: High Should be handled next stale Automatic marker for inactivity, please have another look here T: Bug Wrong statements in the code or documentation
Projects
Status: Done
Development

No branches or pull requests

5 participants