(0014513)
Alex Neundorf (developer)
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 (reporter)
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) (developer)
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) (developer)
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) (developer)
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 (developer)
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) (developer)
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) (developer)
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 (manager)
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.

Issue History
Date Modified	Username	Field	Change
2008-12-18 19:27	Markus Grabner	New Issue
2008-12-18 19:27	Markus Grabner	File Added: python_shared_lib.patch
2009-01-10 08:27	Alex Neundorf	Note Added: 0014513
2009-01-10 08:27	Alex Neundorf	Category	CMake => Modules
2009-01-12 08:56	Markus Grabner	Note Added: 0014529
2009-01-12 08:56	Markus Grabner	File Added: cmake-python_shared_lib.patch
2009-01-30 16:43	Marcus Hanwell (old account)	Note Added: 0014741
2009-01-30 16:45	Marcus Hanwell (old account)	Note Added: 0014742
2009-09-14 15:08	Bill Hoffman	Status	new => assigned
2009-09-14 15:08	Bill Hoffman	Assigned To	=> Alex Neundorf
2009-10-19 10:42	Marcus Hanwell (old account)	Note Added: 0018105
2009-10-19 17:07	Alex Neundorf	Note Added: 0018115
2009-10-19 17:08	Alex Neundorf	Assigned To	Alex Neundorf => Marcus Hanwell (old account)
2009-10-19 17:19	Marcus Hanwell (old account)	Resolution	open => fixed
2009-10-19 17:19	Marcus Hanwell (old account)	Product Version	CMake-2-6 => CMake-2-8
2009-10-19 17:20	Marcus Hanwell (old account)	Note Added: 0018116
2009-12-14 14:16	Marcus Hanwell (old account)	Note Added: 0018868
2009-12-14 14:16	Marcus Hanwell (old account)	Status	assigned => closed
2009-12-14 14:16	Marcus Hanwell (old account)	Fixed in Version	=> CMake-2-8
2011-01-26 10:59	David Cole	Assigned To	Marcus Hanwell (old account) => Marcus D. Hanwell
2011-01-26 10:59	David Cole	Status	closed => assigned
2011-01-26 11:06	David Cole	Note Added: 0025089
2011-01-26 11:06	David Cole	Status	assigned => closed

Notes
(0014513) Alex Neundorf (developer) 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 (reporter) 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) (developer) 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) (developer) 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) (developer) 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 (developer) 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) (developer) 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) (developer) 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 (manager) 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.

Relationships