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 finding Python library and Python interpreter mismatch during pybind11 build #99

Closed
jthetzel opened this issue Feb 8, 2016 · 16 comments

Comments

@jthetzel
Copy link

jthetzel commented Feb 8, 2016

CMake finds mismatched PythonLibs and PythonInterp on my machine with multiple Python installations. PythonLibs finds 2.7.10, while PythonInterp finds 2.7.11:

$ cmake .
-- Setting build type to 'MinSizeRel' as none was specified.
-- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.10")
CMake Error at /usr/local/Cellar/cmake/3.4.1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find PythonInterp: Found unsuitable version "2.7.11", but
  required is exact version "2.7.10" (found /usr/local/bin/python2.7)
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.4.1/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/Cellar/cmake/3.4.1/share/cmake/Modules/FindPythonInterp.cmake:162 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:37 (find_package)

-- Configuring incomplete, errors occurred!
See also "/Users/jthetzel/src/pybind11/CMakeFiles/CMakeOutput.log".

Specifying -DPYTHON_INCLUDE_DIR seems to bypass the error, though it warns that EXACT is being ignored. However, PythonInterp now finds Python 3.5.1:

$ rm CMakeCache.txt
$ cmake -DPYTHON_INCLUDE_DIR=/usr/local/bin/python .
-- Setting build type to 'MinSizeRel' as none was specified.
-- Found PythonLibs: /usr/lib/libpython2.7.dylib
CMake Warning (dev) at CMakeLists.txt:37 (find_package):
  Ignoring EXACT since no version is requested.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PythonInterp: /usr/local/bin/python3.5 (found version "3.5.1")
-- Performing Test HAS_CPP14_FLAG
-- Performing Test HAS_CPP14_FLAG - Success
-- Performing Test HAS_CPP11_FLAG
-- Performing Test HAS_CPP11_FLAG - Success
-- Performing Test HAS_LTO_FLAG
-- Performing Test HAS_LTO_FLAG - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/jthetzel/src/pybind11

I have three Pythons installed, 2.7.11 and 3.5.1 via homebrew in /usr/local/bin/, and 2.7.10 via the OSX system installation in /usr/bin/:

$ which -a python
/usr/local/bin/python
/usr/bin/python

$ which -a python3
/usr/local/bin/python3

$ /usr/local/bin/python --version
Python 2.7.11
$ /usr/bin/python --version
Python 2.7.10
$ /usr/local/bin/python3 --version
Python 3.5.1

/usr/local/bin/python is expected to be found first in PATH:

$ echo $PATH
/Users/jthetzel/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin

$ python --version
Python 2.7.11

From a related closed pull request, this appears to be the fault of CMake ( https://github.com/wjakob/pybind11/pull/65 ), not specifically pybind11. Still, it would be nice to have a safe workaround, as having homebrew and system Python installations will likely be common for users in OSX environments. I'll take a closer look tonight.

Some version information:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.3
BuildVersion:   15D21

$ cmake --version
cmake version 3.4.1

$ git rev-parse --short HEAD
4f8902a
@wjakob
Copy link
Member

wjakob commented Feb 8, 2016

After a number of attempts trying to patch up the detection logic, I welcome external patches to fix this.

@jthetzel
Copy link
Author

jthetzel commented Feb 9, 2016

After reading through the numerous related bug reports involving homebrew, Python, and CMake, especially Homebrew/legacy-homebrew#25118 and http://www.itk.org/Bug/view.php?id=14809 , which you have contributed to, I developed a strong headache and stopped. I especially enjoyed this four year-old quote: "Basically, CMake clings to Frameworks like a drowning sailor on OSX" from Homebrew/legacy-homebrew#10393 (comment) . The issue persists in CMake 3.5.0-rc1.

For now, I can ask CMake to use the OSX system Python interpreter with cmake -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python . . I'll take another stab at a patch this weekend. Otherwise, the issue should be closed as upstream.

@jkhoogland
Copy link

I have some cmake logic I wrote to handle use of Anaconda python here.

It is not exactly your use case, but it might give you some idea how to proceed.

@wjakob
Copy link
Member

wjakob commented Feb 10, 2016

Yes,that looks useful. Supporting the default Python distribution is obviously a requirement ;)

@ibell
Copy link
Contributor

ibell commented Mar 13, 2016

You might also want to investigate FindPythonLibsNew.cmake . For instance from here: https://github.com/usnistgov/REFPROP-wrappers/blob/master/cmake/FindPythonLibsNew.cmake

It helped me with some of these issues.

@ideoforms
Copy link

Encountered the same problem here. If you need to build against the non-system (Homebrew) Python install, this workaround does the trick:

cmake -DPYTHON_LIBRARY=$(python-config --prefix)/lib/libpython2.7.dylib -DPYTHON_INCLUDE_DIR=$(python-config --prefix)/include/python2.7 .

wjakob added a commit that referenced this issue Apr 14, 2016
@wjakob
Copy link
Member

wjakob commented Apr 14, 2016

Closing this as WONTFIX, as it's not a pybind11 issue.

@wjakob wjakob closed this as completed Apr 14, 2016
arummler added a commit to arummler/eudaq that referenced this issue Aug 20, 2016
- 0b91e48 Update TravisCI: build master, but omit OS X since I still haven't figured out what goes wrong on the Travis machine, somehow the compiler flags are selected wrongly...
- 697f039 TravisCI: try moving to Trusty which provides ROOT and a recent GCC
- 8828506 Try to fix missing packages with preventive apt-get update
- cd010ae Add additional CMake hint for ROOT package installed on Trusty platforms
- ced60a6 The packaged ROOT is lacking "TPaletteAxis.h" for some reason. I'm getting a bit angry and am turning off the OnlineMon build for now.
- 412e994 Added appveyor.yml for automatized Windows build on appyevor: https://ci.appveyor.com Needs just a registration of the repository similar as Travis and both of them should be able to run at the same time: https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
- d92746a Changed .travis.yml in a way that instead of using the root-system from the Ubuntu repository which is traditionally a bit strange the precompiled version from the CERN root web site is loaded. Now the OnlineMon is reanbled for the Linux build.
- 047810b Wrong branch name in appveyor.yml
- 638fd78 With the removal of the hand assigned compiler flags (relying on cmake) it also compiles again on OSX. Added modern cmake 3.4 as the provided one is too old: 2.8.
+ b405426 Add qt to OSX.
+ 106c5b2 Switched CI settings from v1.5-dev branch to v1.6-dev as 1.6 release has been published.
+ 21f589b Fixed CI badges for v1.6-dev
+ 1ae0ffa Formatting README.md v1.6-dev got lost
+ 8466bfe Forgot to change hard coded version for 1.6
+ 3dc0a9b Forgot to change hard coded version for 1.6
+ e897f4e Reduce noise in appveyor build (see http://help.appveyor.com/discussions/problems/4569-the-target-_convertpdbfiles-listed-in-a-beforetargets-attribute-at-c-does-not-exist-in-the-project-and-will-be-ignored).
+ 99376b9 Appveyor CI: Updated appveyor to ROOT 5.34.36 (still for MSVC 2012 but it seems to work...) and Qt 5.6/MSVC 2015.
+ 4b702dc Travis CI: Updated travis ROOT to 5.34.36
+ 906dc5d Travis CI: Creating option branches
+ 0ffb506 Travis CI: Corrected the file permissions of helper scripts
+ f2cc2ec Travis CI: More progress on travis options. Renamed travis env variable. Travis env context
+ dbdf7cf Travis CI: QT5 added
+ 92372dd Travis CI: Install python3 on travis for modern option
+ a4ce2d8 Travis CI: Switch on all producers
+ bc37bf9 Travis CI: Do not build palpidefs on travis as it requires external dependencies
+ 9ae0e93 Travis CI: Adding openafs to travis
+ 0707986 Travis CI: Added more producers
+ 3cf1509 Travis CI: Removed pixelman producer from travis build and checking why afs not recognized
+ b6a6ddf Travis CI: Added kernel headers for OpenAFS module
+ 50dbc41 Travis CI: Added openafs repo to travis linux
+ ea949f1 Travis CI: Start openafs after module installation
+ d19ae7d Travis CI: Added libusb to travis
+ 5904a58 Travis CI: For travis download only necessary parts of ZestSC, otherwise awfully slow.
+ 639fd8b Cmake syntax error
+ 7b6a31c Travis CI: Removed pybar from travis as it seems to be no longer in 1.6 and following
+ 4857c1a Travis CI: Removing Altro from build due to known issues
+ 7a2b477 Travis CI: Removing mvd from travis build due to known issues
+ 613b669 Travis CI: Removing calice from the travis build until it is fixed
+ a16e29e Removing depfet from travis build as it fails.
+ 3b3d24c Travis CI: Readding depfet to travis after Simon's fix
+ e618a86 Travis CI: Install OpenAFS on Mac
+ e96e656 Travis CI: Reenable calice option
+ 7bccc9a Travis CI: Disable eudrb as it is only supposed to run on single board computers
+ 2c00b5c Appveyor CI: Install OpenAFS on Windows
+ 5bb53e4 Travis CI: Changing cmake flags
+ e6fb0c4 Travis CI: Compile manual on linux
+ ad242e6 Appveyor CI: Remove remote desktop conenction (only for debugging, leave it commented)
+ 6f5b10e Travis CI: Change cmake parametres
+ d940170 Travis CI: Change python handling
+ bbc3553 Fix problem with cmake on mac (framework version mismatch):     https://github.com/usnistgov/REFPROP-wrappers/blob/master/cmake/FindPythonLibsNew.cmake     pybind/pybind11#99     http://stackoverflow.com/questions/30470628/os-x-cmake-cant-find-pythonlibs-3-4     Homebrew/legacy-homebrew#10393 (comment)
+ d7fa3d1 Travis CI: Updated root 6 version
+ 71d0057 Travis CI more work on python installation for mac and linux.
+ 4fe72ea Appveyor CI: Installation of supporter programs, openafs, ...
+ 8bb32e5 Appveyor CI: Install python including numpy
+ c52c1e8 - Solved openafs problem on travis CI - Updated hard coded version to 1.7 - General clean up of CI oriented files - Reverted FINDLIBusb.cmake test output as it is no longer necessary after debugging - Prepared travis and appveyor githb release upload; needs to be tested after merge
+ b76f64a Appveyor CI: Repair syntax error in yml file.
+ ceb7d9e Appveyor CI: Fixing artefact generation
+ 39ae109 CI: Changing branch name for symbols in README.me (show on the top page of github)
SimonRit pushed a commit to RTKConsortium/RTK that referenced this issue Jun 29, 2017
@MrBean947724451
Copy link

Delete CMakeLists.txt which will cache make config .If the first time you use python 2.7 ,the file can remerber python path,and use it . so JUST DELETE CMAKELISTS.TXT!

@ibell
Copy link
Contributor

ibell commented Dec 21, 2017 via email

@MrBean947724451
Copy link

MrBean947724451 commented Dec 21, 2017 via email

@xylcbd
Copy link

xylcbd commented Jan 9, 2019

cmake -DPYTHON_EXECUTABLE=which python ..

@benDavidson6
Copy link

I had to provide the following flags

-DPYTHON_EXECUTABLE=C:\Users\Ben\Anaconda3\envs\py3.7\python.exe 
-DPYTHON_INCLUDE_DIR=C:\Users\Ben\Anaconda3\envs\py3.7\include 
-DPYTHON_LIBRARY=C:\Users\Ben\Anaconda3\envs\py3.7\libs

@xmba15
Copy link

xmba15 commented Sep 14, 2019

I have written a script to find cmake variables for pyenv python.
https://github.com/xmba15/oh_my_cmakes/blob/master/cmake/FindPythonPyenv.cmake

So basically, add these lines before add_subdirectory(pybind11)

execute_process(
  COMMAND which python
  OUTPUT_VARIABLE PYTHON_EXECUTABLE OUTPUT_STRIP_TRAILING_WHITESPACE
)

execute_process(
  COMMAND python -c "from __future__ import print_function; from distutils.sysconfig import get_python_inc; print(get_python_inc())"
  OUTPUT_VARIABLE PYTHON_INCLUDE_DIR OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_QUIET
)

execute_process(
  COMMAND python -c "from __future__ import print_function; import os, numpy.distutils; print(os.pathsep.join(numpy.distutils.misc_util.get_numpy_include_dirs()))"
  OUTPUT_VARIABLE PYTHON_NUMPY_INCLUDE_DIR OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_QUIET
)

execute_process(
  COMMAND python -c "from __future__ import print_function; import distutils.sysconfig as sysconfig; print(sysconfig.get_config_var('LIBDIR') + '/' + sysconfig.get_config_var('LDLIBRARY'))"
  OUTPUT_VARIABLE PYTHON_LIBRARY OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_QUIET
)

execute_process(
  COMMAND python -c "from __future__ import print_function; import platform; print(platform.python_version())"
  OUTPUT_VARIABLE PYTHONLIBS_VERSION_STRING OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_QUIET
)

then ${PYTHON_EXECUTABLE}, ${PYTHON_INCLUDE_DIR}, ${PYTHON_NUMPY_INCLUDE_DIR}, ${PYTHON_LIBRARY} of pyenv will be fed into pybind11.

@misterjoa
Copy link

In case that might help, I found a workaround for a similar problem, looking at the cmake doc :
https://cmake.org/cmake/help/v3.0/module/FindPythonLibs.html

You must set two env vars for cmake to find coherent versions
Unfortunately this is not a generic solution but still, it works !

cmake -DPYTHON_LIBRARY=${HOME}/.pyenv/versions/3.8.0/lib/libpython3.8.a -DPYTHON_INCLUDE_DIR=${HOME}/.pyenv/versions/3.8.0/include/python3.8/ cern_root/

knarfS added a commit to knarfS/pybind11 that referenced this issue Feb 8, 2020
This is needed when using linuxdeploy / appimagecraft to create an AppImage
and when cross compiling (f.e. with MXE) to find the python libraries.
You may need to set CMAKE_FIND_ROOT_PATH_MODE_LIBRARY to BOTH when cross
compiling.

This may fix issues pybind#1718, pybind#1159, pybind#1330 and pybind#99.
knarfS added a commit to knarfS/pybind11 that referenced this issue Apr 11, 2020
This is needed when using linuxdeploy / appimagecraft to create an AppImage
and when cross compiling (f.e. with MXE) to find the python libraries.
You may need to set CMAKE_FIND_ROOT_PATH_MODE_LIBRARY to BOTH when cross
compiling.

This may fix issues pybind#1718, pybind#1159, pybind#1330 and pybind#99.
knarfS added a commit to knarfS/pybind11 that referenced this issue Apr 20, 2020
This is needed when using linuxdeploy / appimagecraft to create an AppImage
and when cross compiling (f.e. with MXE) to find the python libraries.
You may need to set CMAKE_FIND_ROOT_PATH_MODE_LIBRARY to BOTH when cross
compiling.

This may fix issues pybind#1718, pybind#1159, pybind#1330 and pybind#99.
@amritas02
Copy link

I had the same problem, and once I managed to solve this problem - which was adding a couple lines setting the variables python_library and python_include in the Cmakelists.txt , I ran into Boost problems.

The way I solved this was uninstalling python using homebrew and reinstalling python and linking it properly. After that pip3 install . worked in one go.

knarfS added a commit to knarfS/pybind11 that referenced this issue Aug 15, 2020
This is needed when using linuxdeploy / appimagecraft to create an AppImage
and when cross compiling (f.e. with MXE) to find the python libraries.
You may need to set CMAKE_FIND_ROOT_PATH_MODE_LIBRARY to BOTH when cross
compiling.

This may fix issues pybind#1718, pybind#1159, pybind#1330 and pybind#99.
@WilliamTambellini
Copy link

WilliamTambellini commented Jan 31, 2023

FYI: still an issue with latest cmake, cf:
https://cmake.org/cmake/help/v3.24/module/FindPython3.html#module:FindPython3

sschnug pushed a commit to sschnug/pybind11 that referenced this issue Aug 2, 2024
updates:
- [github.com/asottile/pyupgrade: v3.1.0 → v3.2.0](asottile/pyupgrade@v3.1.0...v3.2.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
h-vetinari added a commit to h-vetinari/faiss-split-feedstock that referenced this issue Aug 7, 2024
it's worth noting that:
* One needs `-DPython...` or `-DPython3...` depending on whether the respective
  CMakeLists.txt does `find_package(Python ...)` or `find_package(Python3 ...)`. [0]
* The error messages are actively misleading, as
  ```
  Could NOT find Python (missing: Python_INCLUDE_DIRS Python_LIBRARIES
  Python_NumPy_INCLUDE_DIRS Development NumPy Development.Module
  Development.Embed)
  ```
  suggests that the variables in question use plural `_DIRS` / `_LIBRARIES`, yet
  what's actually required is the singular. [1]
* The key flag is `Python_NumPy_INCLUDE_DIR`; other times `Python_EXECUTABLE` or
  `Python_ROOT` may prove useful.

Inspired by work [2] from the pinocchio-feedstock (thank you!), though the actual
copying turns out to not be necessary.

And if you've read this far, you get this lovely bonus comment [3]. :)

[0] https://github.com/facebookresearch/faiss/blob/v1.8.0/faiss/python/CMakeLists.txt#L153
[1] https://cmake.org/cmake/help/latest/module/FindPython.html
[2] https://github.com/conda-forge/pinocchio-feedstock/blob/main/recipe/build.sh
[3] pybind/pybind11#99 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests