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

CMake finds wrong F2PY #449

Closed
bnavigator opened this issue Sep 22, 2019 · 1 comment
Closed

CMake finds wrong F2PY #449

bnavigator opened this issue Sep 22, 2019 · 1 comment
Labels
Category: CMake Related to CMake modules Type: Bug Something's not working correctly.

Comments

@bnavigator
Copy link
Contributor

I know CMake suggests to put the unversioned filename in front for the find_program() call:

NAMES
Specify one or more possible names for the program.

When using this to specify names with and without a version suffix, we recommend specifying the unversioned name first so that locally-built packages can be found before those provided by distributions.

But in the case of python files this is counterproductive. When you want to build a project for Python 2 where both Python 2 and 3 are installed, this call always finds the default f2py:

find_program(F2PY_EXECUTABLE NAMES f2py f2py${PYTHON_VERSION_MAJOR})

At python-control/Slycot#81 this lead to a hard to track down free(): invalid pointer error in the python2 packaging for Arch Linux and OpenSUSE, because the wrong f2py was used. As a workaround one can provide the path to the correct executable by adding the variable explicitly during the build call:
python2 setup.py build -- -DF2PY_EXECUTABLE=/usr/bin/f2py2

I suggest putting the unversioned filename to the end of the find_program() call and additionally making sure that the f2py is from the correct numpy.

@bnavigator bnavigator mentioned this issue Sep 22, 2019
@jcfr jcfr added Category: CMake Related to CMake modules Type: Bug Something's not working correctly. labels Sep 24, 2019
@jcfr
Copy link
Contributor

jcfr commented Sep 24, 2019

Thanks for the suggestion 🙏 , makes sense. I am integrating the corresponding change now. I will also make sure to give you credit for the contribution 👍

jcfr added a commit to jcfr/scikit-build that referenced this issue Sep 24, 2019
@jcfr jcfr closed this as completed Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: CMake Related to CMake modules Type: Bug Something's not working correctly.
Projects
None yet
Development

No branches or pull requests

2 participants