MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013794CMakeCMakepublic2012-12-13 19:472015-04-06 09:07
ReporterTobias Pfaff 
Assigned ToMatt McCormick 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinuxOSUbuntuOS Version12.10
Product VersionCMake 2.8.10.2 
Target VersionFixed in VersionCMake 3.1 
Summary0013794: find_package(PythonLibs) finds different version of Python headers and libraries
DescriptionPythonLibs returns inconsistent versions for lib and include dir:
PYTHON_INCLUDE_DIR = /usr/include/python2.7
PYTHON_LIBRARIES = /usr/lib/python3.2/config/libpython3.2.so
resulting in linker errors.
The latter is probably the culprit, see cmake output:

Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version "2.7.3")

The 2.7 version is in /usr/lib/python2.7/config/libpython2.7.so

This problem is probably specific to Ubuntu 12.10. It ships with 3.2 libraries on default, but no headers (unless you install python3-dev). It applies to both cmake version 2.8.9 (which comes with the distribution) and the newest 2.8.10.2.

I have not found a workaround yet -- apart from directly specifying the directories, which is not an option as I am distributing my code, and it should run on all client configurations.
Python_ADDITIONAL_VERSIONS e.g. do not help.
Steps To Reproducefind_package(PythonLibs REQUIRED)
message(${PYTHON_INCLUDE_DIRS})
message(${PYTHON_LIBRARIES})

on Ubuntu 12.10, with package python-dev installed (but python3-dev NOT installed)
Additional Information
TagsNo tags attached.
Relationships
has duplicate 0010077closed  FindPythonInterp and FindPythonLibs result in inconsistent python versions 
related to 0014271closed Matt McCormick find_package PythonInterp and PythonLibs are not consistent 
Attached Filespatch adamwwolf-FindPythonLibs.patch (1,050) 2013-04-29 14:35
https://public.kitware.com/Bug/file/4752/adamwwolf-FindPythonLibs.patch
Issue History
Date ModifiedUsernameFieldChange
2012-12-13 19:47Tobias PfaffNew Issue
2012-12-14 03:04Marcel LooseNote Added: 0031885
2013-04-03 13:28Orion PoplawskiNote Added: 0032751
2013-04-29 14:34Adam WolfNote Added: 0032961
2013-04-29 14:35Adam WolfFile Added: adamwwolf-FindPythonLibs.patch
2013-08-28 12:11Orion PoplawskiNote Added: 0033755
2013-08-28 13:12Orion PoplawskiNote Added: 0033756
2014-02-26 07:09Gert WollnyNote Added: 0035201
2014-02-26 21:59Matthew McCormickNote Added: 0035211
2014-03-03 10:04Brad KingNote Added: 0035233
2014-03-03 10:05Brad KingAssigned To => Matt McCormick
2014-03-03 10:05Brad KingStatusnew => resolved
2014-03-03 10:05Brad KingResolutionopen => fixed
2014-03-03 10:05Brad KingFixed in Version => CMake 3.1
2014-03-03 10:05Brad KingTarget Version => CMake 3.1
2014-03-05 11:46Brad KingRelationship addedhas duplicate 0010077
2014-03-05 11:48Brad KingNote Added: 0035306
2014-03-05 11:48Brad KingStatusresolved => assigned
2014-03-05 11:48Brad KingResolutionfixed => reopened
2014-03-05 12:02Brad KingNote Added: 0035307
2014-03-05 12:02Brad KingNote Edited: 0035307bug_revision_view_page.php?bugnote_id=35307#r1396
2014-03-05 12:38Brad KingResolutionreopened => open
2014-03-05 12:38Brad KingFixed in VersionCMake 3.1 =>
2014-03-05 13:59Matthew McCormickNote Added: 0035314
2014-03-05 14:38Brad KingNote Added: 0035316
2014-03-05 17:39Matthew McCormickNote Added: 0035322
2014-03-05 17:52Matthew McCormickNote Added: 0035323
2014-03-06 10:57Orion PoplawskiNote Added: 0035328
2014-03-13 09:26Brad KingNote Added: 0035392
2014-03-13 11:23Matthew McCormickNote Added: 0035393
2014-03-14 09:15Brad KingNote Added: 0035403
2014-03-26 11:06Brad KingRelationship addedrelated to 0014271
2014-04-03 20:35Nikolaus DemmelNote Added: 0035634
2014-04-03 20:48Matthew McCormickNote Added: 0035635
2014-04-04 10:21Nikolaus DemmelNote Added: 0035639
2014-04-04 11:26Brad KingNote Added: 0035641
2014-10-03 09:34Brad KingNote Added: 0036898
2014-10-03 09:34Brad KingTarget VersionCMake 3.1 =>
2014-10-03 12:45Matthew McCormickNote Added: 0036899
2014-10-03 13:19Brad KingStatusassigned => resolved
2014-10-03 13:19Brad KingResolutionopen => fixed
2014-10-03 13:19Brad KingFixed in Version => CMake 3.1
2015-04-06 09:07Robert MaynardNote Added: 0038415
2015-04-06 09:07Robert MaynardStatusresolved => closed

Notes
(0031885)
Marcel Loose   
2012-12-14 03:04   
I ran into this problem as well. It suffices to specify a version number, i.e.

FIND_PACKAGE(PythonLibs 2.7 REQUIRED)

This will find any Python 2 libraries with version number 2.7 or higher.
(0032751)
Orion Poplawski   
2013-04-03 13:28   
We're seeing this on Fedora too: https://bugzilla.redhat.com/show_bug.cgi?id=876118 [^]

Version workaround appears to not work there.
(0032961)
Adam Wolf   
2013-04-29 14:34   
I made a very small patch to CMake to fix this problem. I tested it on Ubuntu, which has also been having this problem for a while.
(0033755)
Orion Poplawski   
2013-08-28 12:11   
Ping - can we get this addressed please?
(0033756)
Orion Poplawski   
2013-08-28 13:12   
FYI - The patch appears to work for us too. I'll be adding it to the Fedora package.
(0035201)
Gert Wollny   
2014-02-26 07:09   
The major problem with the propose patch is that it only helps when the Python interpreter is searched for first.

However, e.g. ITK is doing

  find_package(PythonLibs)
  find_package(PythonInterp)

so that the patch will not help. My suggestion would be to let FindPythonLibs call FindPythonInterp and use this result (if availble) with the above patch.

If someone really wants to find versions of interpreter and libraries that are different from each other then she can still use the explicit specification of versions.
(0035211)
Matthew McCormick   
2014-02-26 21:59   
Pushed to stage:

  http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/different-python-header-libs-exe-0013794 [^]

Please review.
(0035233)
Brad King   
2014-03-03 10:04   
Re 0013794:0035211: Here is a more permanent link to the change:

 FindPythonLibs: Find consistent Python interp, headers, libs
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3816cd2d [^]
(0035306)
Brad King   
2014-03-05 11:48   
The patch linked in 0013794:0035233 resulted in problems reported here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9594 [^]
(0035307)
Brad King   
2014-03-05 12:02   
Re 0013794:0035306: Here is another commit to address the reported problems. We should not try to find the interpreter if the project did not ask for it just to find its version. The requested version of the interpreter may not be found:

 FindPythonLibs: Do not try to find the interpreter
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf28ff1f [^]
(0035314)
Matthew McCormick   
2014-03-05 13:59   
With

 FindPythonLibs: Do not try to find the interpreter
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf28ff1f [^] [^]

If

 find_package(PythonLibs)
 find_package(PythonInterp)

happen to be called in that order, inconsistent versions are still found.
(0035316)
Brad King   
2014-03-05 14:38   
Re 0013794:0035314: So add a similar change to FindPythonInterp. At least now there is *a* way to get consistent versions.
(0035322)
Matthew McCormick   
2014-03-05 17:39   
Here is a patch that adds a similar change to FindPythonInterp:

  http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=4a48d7c14e4f6a1e490ef6953a7655d5bf26eb16 [^]

A default system is installed "python" adds difficulty, but I think it is the best way to get a consistent version without calling find_package(PythonInterp) inside FindPythonLibs.cmake.
(0035323)
Matthew McCormick   
2014-03-05 17:52   
Patch on the stage different-python-header-libs-exe-0013794 branch:

  http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=3c4da3e39eb5f7267a0098602b68380717d4a6ed [^]
(0035328)
Orion Poplawski   
2014-03-06 10:57   
Current version of FindPythonLibs fixed the reported Fedora issue. Thanks.
(0035392)
Brad King   
2014-03-13 09:26   
Re 0013794:0035323: That commit prints a warning if FindPythonLibs has been loaded first. That will warn even when a project does

 find_package(PythonInterp)
 find_package(PythonLibs)

and later does

 find_package(PythonInterp)

again. I think information like that should go in the documentation but not a warning.
(0035393)
Matthew McCormick   
2014-03-13 11:23   
Good point. Added here:

  http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=9589c70b0b89f462b6325c815963c118cb1e16e1 [^]
(0035403)
Brad King   
2014-03-14 09:15   
Patches from 0013794:0035323 and 0013794:0035393 revised as:

 FindPythonInterp: Use consistent version with PythonLibs
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9e6de2a [^]

 FindPython*: Document suggested find_package order
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=59220198 [^]
(0035634)
Nikolaus Demmel   
2014-04-03 20:35   
One question about this patch. What does the line

    list(APPEND _Python_VERSIONS ";")

do? I would have expected to find something like

    list(APPEND _Python_VERSIONS "python")

there instead. Am I mistaken, or does the module with this patch not look for the "python" command (no version number) any more? Even if no version is specified?
(0035635)
Matthew McCormick   
2014-04-03 20:48   
The ";" entry corresponds to an empty entry in the list, which causes it to look for "python".
(0035639)
Nikolaus Demmel   
2014-04-04 10:21   
Thanks for the clarification. I got confused about this list containing only version numbers, not the full executable string. Also ";" resulting in an empty entry is not very intuitive for the CMake noob like myself. (I'm looking at this while investigating 0014809).
(0035641)
Brad King   
2014-04-04 11:26   
Re 0013794:0035635, 0013794:0035639: Actually appending ";" results in two empty entries because it is a ;-separated list of two empty elements. Just

 list(APPEND _Python_VERSIONS "")

should be enough to append an empty list entry.
(0036898)
Brad King   
2014-10-03 09:34   
The patches in 0013794:0035403 are now in 'master'. Are there remaining issues here?
(0036899)
Matthew McCormick   
2014-10-03 12:45   
To the best of my knowledge, this issue is addressed, at least in how was described in the original bug report.
(0038415)
Robert Maynard   
2015-04-06 09:07   
Closing resolved issues that have not been updated in more than 4 months.