[Wheel-builders] Error from numpy wheel - any thoughts

[Jonathan Helmus]

On 03/30/2016 04:07 AM, Olivier Grisel wrote:
> Actually with anaconda I get the error even when I do not import numpy first:
>
> $ ~/anaconda3/bin/python -m numpy.f2py -c foo.f90 -m foo &> /dev/null
> $ ~/anaconda3/bin/python -c "import foo"
> Traceback (most recent call last):
>    File "<string>", line 1, in <module>
> ImportError:/home/ogrisel/anaconda3/bin/../lib/libgfortran.so.3:
> version `GFORTRAN_1.4' not found (required by
> /home/ogrisel/code/numpy/numpy/f2py/tests/src/kind/foo.cpython-35m-x86_64-linux-gnu.so)
> ...
>
> --
> Olivier

Those of us working on conda-forge have run into this exact issue and 
are aware of it.  The problem seems to stem from the fact that if you 
ship a runtime library, libgfortran but also libstdc++ or libgcc, which 
shadows a system library, you can (will?) get unresolved symbols at 
runtime if the system library is newer than the one you ship. Discussion 
of the topic can be found in issue 29 of 
conda-forge/conda-forge.github.io [1].

I believe the suggestions of renaming the libgfortran in the wheel 
should fix this issue.   I think the same issue may crop up if you have 
a extension module which links against libstdc++ and perhaps libgcc.  I 
do not have any examples of this, just something to keep in mind.

For completeness, I should mention that to address this problem, 
conda-forge is currently planning on shipping a very recent version (GCC 
5.2) of the various runtime libraries which are linked against a very 
old glibc for compatibility.

Cheers,

     - Jonathan Helmus

[1] https://github.com/conda-forge/conda-forge.github.io/issues/29
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/wheel-builders/attachments/20160330/d2daf391/attachment-0001.html>