Boost and python versions

[dolfim]

I expected conda to lower the problems with mixing python versions when distribution an application using Boost.Python, but reading e.g. #1 it seems that even here it is always a topic.

In particular I'm trying to make a package which depends on boost-python and I get some weird failure in the tests, as if the python/numpy versions do not match. Is there a way to force the version of python to be the same as the one used for building boost? Or the other way around.

I tried to make a simple test that I pushed as a PR conda-forge/staged-recipes#2056.
Could you please help debugging the simple example?

Thanks!

[ccordoba12]

There is a current effort to create a different package for boost-python alone that should solve this problem:

conda-forge/staged-recipes#1887

[isuruf]

This is unrelated to #1.
From travis-ci log, it seems correct packages are used.

Boost, numpy used are compiled with py27 and the python version is also 2.7.

    blas:            1.1-openblas                  conda-forge
    boost:           1.62.0-py27_0                 conda-forge
    bzip2:           1.0.6-3                       defaults   
    ca-certificates: 2016.9.26-0                   conda-forge
    cmake:           3.6.2-0                       conda-forge
    curl:            7.49.1-2                      conda-forge
    expat:           2.1.0-2                       conda-forge
    icu:             56.1-4                        conda-forge
    jsoncpp:         0.10.6-1                      conda-forge
    libarchive:      3.2.1-2                       conda-forge
    libgfortran:     3.0.0-0                       conda-forge
    libiconv:        1.14-3                        conda-forge
    ncurses:         5.9-10                        conda-forge
    numpy:           1.10.4-py27_blas_openblas_205 conda-forge [blas_openblas]
    openblas:        0.2.19-0                      conda-forge
    openssl:         1.0.2h-3                      conda-forge
    python:          2.7.12-1                      conda-forge
    readline:        6.2-0                         conda-forge
    sqlite:          3.13.0-1                      conda-forge
    tk:              8.5.19-1                      conda-forge
    toolchain:       2.0.0-0                       conda-forge
    xz:              5.2.2-0                       conda-forge
    zlib:            1.2.8-3                       conda-forge

[dolfim]

Yes, I think it is not related to #1.

Thanks to the PR by @shadowwalkersb at dolfim/staged-recipes#1 I think the problem is the presence of two incompatible libboost libraries in the conda package.

# this seems to work
${PREFIX}/lib/libpython2.7.dylib

vs

# this gives me problems
${PREFIX}/lib/python2.7/config/libpython2.7.dylib

The latter one is actually provided by

import string; from distutils.sysconfig import *; print(get_config_vars('LIBPL'))

Is this a Conda bug? Where should it be reported?

[isuruf]

${PREFIX}/lib/python2.7/config/libpython2.7.a is provided for embedding python. See here
Since you are not embedding python in this case, you are actually using the static python library in config folder and also linking with the dynamic library when a python session is started and your extension is loaded.

[dolfim]

Thanks for the link, I was actually looking for a better explanation of LIBPL.

The point is that we have been linking against ${PREFIX}/lib/python2.7/config/libpython2.7.dylib for years without any problem. Also on a clean system I can link that way and everything works.

I put a simple Docker build in a clean Ubuntu environment at dolfim/boost-python-numpy.

The error I get in the Conda build somehow looks like a mismatch of the Python version.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: __init__() should return None, not 'NoneType'

[shadowwalkersb]

Which Python is used to run the script? Seems like Dockerfile uses the system Python.

[isuruf]

Conda's python package doesn't provide any ${PREFIX}/lib/python2.7/config/libpython2.7.dylib right? So you might be linking to an incorrect python library.
In my system python, ${PREFIX}/lib/python2.7/config/libpython2.7.so is symlinked to ${PREFIX}/lib/libpython.so which means there is no difference.

[dolfim]

@shadowwalkersb : yes, the example built with Docker is just system standard system python and boost. It was to illustrate that linking against ${PREFIX}/lib/python2.7/config/libpython2.7.soactually works.

@isuruf : yes Conda doesn't seem to provide ${PREFIX}/lib/python2.7/config/libpython2.7.dylib, but the static lib is there.

I would anyway assume that the two libs could be interchangeable, but this doesn't seem to be the case.

[jakirkham]

Is there still an issue that needs to be solve here or is this effectively the same as issue ( #28 )?

[isuruf]

If this is still an issue, this needs to be moved to the python-feedstock.

[jschueller]

I hink we can close this as boost.python is split now