MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008319CMakeModulespublic2008-12-18 19:272011-01-26 11:06
ReporterMarkus Grabner 
Assigned ToMarcus D. Hanwell 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in VersionCMake-2-8 
Summary0008319: FindPythonLibs.cmake doesn't find shared object
DescriptionFindPythonLibs.cmake doesn't find libpython2.x.so since it only searches with PATH_SUFFIXES set to "python${_CURRENT_VERSION}/config". Adding an empty suffix ("") to the list solves the problem.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch python_shared_lib.patch (641) 2008-12-18 19:27
https://public.kitware.com/Bug/file/1935/python_shared_lib.patch
patch cmake-python_shared_lib.patch (552) 2009-01-12 08:56
https://public.kitware.com/Bug/file/1987/cmake-python_shared_lib.patch
Issue History
Date ModifiedUsernameFieldChange
2008-12-18 19:27Markus GrabnerNew Issue
2008-12-18 19:27Markus GrabnerFile Added: python_shared_lib.patch
2009-01-10 08:27Alex NeundorfNote Added: 0014513
2009-01-10 08:27Alex NeundorfCategoryCMake => Modules
2009-01-12 08:56Markus GrabnerNote Added: 0014529
2009-01-12 08:56Markus GrabnerFile Added: cmake-python_shared_lib.patch
2009-01-30 16:43Marcus Hanwell (old account)Note Added: 0014741
2009-01-30 16:45Marcus Hanwell (old account)Note Added: 0014742
2009-09-14 15:08Bill HoffmanStatusnew => assigned
2009-09-14 15:08Bill HoffmanAssigned To => Alex Neundorf
2009-10-19 10:42Marcus Hanwell (old account)Note Added: 0018105
2009-10-19 17:07Alex NeundorfNote Added: 0018115
2009-10-19 17:08Alex NeundorfAssigned ToAlex Neundorf => Marcus Hanwell (old account)
2009-10-19 17:19Marcus Hanwell (old account)Resolutionopen => fixed
2009-10-19 17:19Marcus Hanwell (old account)Product VersionCMake-2-6 => CMake-2-8
2009-10-19 17:20Marcus Hanwell (old account)Note Added: 0018116
2009-12-14 14:16Marcus Hanwell (old account)Note Added: 0018868
2009-12-14 14:16Marcus Hanwell (old account)Statusassigned => closed
2009-12-14 14:16Marcus Hanwell (old account)Fixed in Version => CMake-2-8
2011-01-26 10:59David ColeAssigned ToMarcus Hanwell (old account) => Marcus D. Hanwell
2011-01-26 10:59David ColeStatusclosed => assigned
2011-01-26 11:06David ColeNote Added: 0025089
2011-01-26 11:06David ColeStatusassigned => closed

Notes
(0014513)
Alex Neundorf   
2009-01-10 08:27   
On which operating system ?
Where is your libpython2.x.so installed exactly ?
On my system it finds PYTHON_LIBRARY /usr/lib/python2.5/config/libpython2.5.a.
What does it find for you ? Nothing or also the static lib ?

Alex
(0014529)
Markus Grabner   
2009-01-12 08:56   
I'm using openSUSE-11.0 (Linux kernel 2.6.25.18, x86_64). The python library is "/usr/lib64/libpython2.5.so", the cmake module finds the static version "/usr/lib64/python2.5/config/libpython2.5.a" instead (i.e., programs using PYTHON_LIBRARIES are working, but are considerably larger). There is a comment

# Avoid finding the .dll in the PATH. We want the .lib.

in "FindPythonLibs.cmake". Does that mean that finding the static library is the desired behavior under Windows? Under Linux, I would prefer to use the dynamic library by default.

Interestingly, when I tried to reproduce the problem on my current system, the previously submitted patch was ineffective. I will upload a revised version.
(0014741)
Marcus Hanwell (old account)   
2009-01-30 16:43   
The second patch works here, /usr/lib64/./libpython2.5.so is set as the library. It appears that most non-Debian distros do not make the symlink to the shared library from the config directory. We need the normal library path to be first in the search order. Is using a . an acceptable way to accomplish this?

We use FindPythonLibs.cmake in Avogadro, and get quite a few bug reports related to this. If it would help I am willing to become a maintainer for FindPythonLibs.cmake. This is quite an old bug and I would love to see it fixed in time for 2.6.3 if possible. Initially all that really requires is ensuring that a no suffix path is searched first and I think that would ensure the shared library is found. See bug 2257 for some more history on this bug.
(0014742)
Marcus Hanwell (old account)   
2009-01-30 16:45   
Looking at Brad's file list, could the PATH_SUFFIX be removed entirely from the library search? It appears to just symlink, /usr/lib/python2.5/config/libpython2.5.so -> ../../libpython2.5.so. So the linking would effectively be the same if Debian always maintains this layout and the module should then work for all Linux distributions I have encountered.
(0018105)
Marcus Hanwell (old account)   
2009-10-19 10:42   
This should now be fixed in revision 1.45 of Modules/FindPythonLibs.cmake. I don't have sufficient privileges to close this bug report. I removed the PATH_SUFFIX, and had tested this solution using Avogadro's build system for several months with no reports of build errors.

Please let me know if you have any further issues.
(0018115)
Alex Neundorf   
2009-10-19 17:07   
Markus, is that you ?
You did something about this bug, so I think it makes sense to assign it to you...
(0018116)
Marcus Hanwell (old account)   
2009-10-19 17:20   
It is me. I marked this issue as fixed as I just got extra prvileges. Please let me know if there are any further issues.
(0018868)
Marcus Hanwell (old account)   
2009-12-14 14:16   
I just committed a small change to ensure the static Python library is found if there is no shared library available. I think this closes all issues related to this bug report - let me know if not.
(0025089)
David Cole   
2011-01-26 11:06   
Whoops... didn't mean to re-open this issue.... Was just changing the "assigned to" from Marcus's old account to his new one to get "Marcus Hanwell (old account)" off my summary view of CMake bugs.