[CMake] What is the proper cross-platform way to link the Python library?

[Alan W. Irwin]

On 2013-01-06 15:54+0100 Arjen Markus wrote:

> On Sun, 06 Jan 2013 11:08:37 +0100
> Rolf Eike Beer <eike at sf-mail.de> wrote:
>
>> This will work as long as PYTHON_LIBRARIES contains only one element.
>> 
>> The debug/optimized keywords apply only to the immediately following 
>> library, so if you have a list of libraries returned (currently unlikely 
>> AFAIK) it may still cause bad results.
>> 
>> Have a look at the SelectLibraryConfigurations module, it does what you did 
>> above and in 2.8.10.* also properly handles lists and the case where both 
>> values are the same.
>> 
>> And from what I see (at least in the current code) FindPythonLibs already 
>> does exaclty that. So which CMake version is Arjen using? And if it is the 
>> most recent one, can you get him to debug why FindPythonLibs doesn't work 
>> as expected?
>> 
>
> I am using CMake version 2.8.10.2 (but IIRC the problem
> also occurred with 2.8.7).
>
> My interpretation of the problem at the moment is:
> - The pyconfig.h header file introduces a dependency of
>  a library "python27_d.lib" directly in the object file
>  - this is the consequence of the pragma.
> - There is no such library in the Python installation,
>  so the linker will always complain that this library
>  is missing - quite independent of what CMake does.
>  (In fact, the generated Makefiles and associated files
>  do not refer to this library at all)
>
> I tried copying the ordinary library to "python27_d.lib"
> but that led to several unresolved symbols. So there is
> more going on than just name mangling.

Hi Arjen and Eike:

I just reinstalled official python from python.org (version 2.7.3 this
time) on Wine, and hit every checkbox to make sure I installed
everything, but I still confirm what Arjen said above (no
"python27_d.lib"). The other possibility was that the debug version of
the library was in quite a different download, but I can see no
potential candidates for special debug versions of python
in the official download area.

So the surprising conclusion must be drawn that the official
python.org pyconfig.h file refers to a file, "python27_d.lib", that is not
officially packaged, and I (and many other python.org users who have
complained about missing python27_d.lib on the net) view that as a bug
in the Windows version of the python.org package.

Until that python.org bug is fixed, CMake Windows users must avoid
situations where this bug is triggered.  So far the only configuration
where this appears to be an issue is the combination of the MSVC
compiler and CMAKE_BUILD_TYPE:STRING=Debug. So for that compiler,
Arjen has proved you are okay if you specify
-DCMAKE_BUILD_TYPE:STRING=Release as a cmake option.  My guess is that
-DCMAKE_BUILD_TYPE:STRING= (i.e., making CMAKE_BUILD_TYPE empty) will
work also, but Arjen hasn't tried that yet. I don't think there are
such restrictions on other Windows compilers such as MinGW, but so far
I have just checked that not specifying CMAKE_BUILD_TYPE at all (which
leads to an empty CMAKE_BUILD_TYPE in the cache by default for MinGW)
works well for the MinGW compiler on a Wine platform.

If/when that python.org bug is fixed I will look into the
SelectLibraryConfigurations module as Eike suggested, but meanwhile I
will stick with my current method

target_link_libraries(<python_target> ${PYTHON_LIBRARIES})

which works cross-platform (so long as you use the above workaround
for the MSVC compiler) and which is consistent with the official
python.org releases which currently include no debug versions of the
library.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________