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
_______________________________________________
Wheel-builders mailing list
[email protected]
https://mail.python.org/mailman/listinfo/wheel-builders
