On Mar 30, 2016 8:01 AM, "Jonathan Helmus" <[email protected]> wrote: > > 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.
It will happen any time you have two different not-quite-compatible versions of the same library being used by different python extensions in the same process. So vendoring libraries is a particularly common place where this will arise of this, as is system library versus distributed libraries, but it's pretty general. > 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. I'm not an expert on conda, but this is probably not the solution I would have chosen? It seems like there will always be some users who have an even-more-recent GCC, and eventually all users will -- so it's embedding a kind of time bomb in all your conda envs. Doesn't conda already have a binary postprocessing step where it inserts rpaths into build artifacts? I'd probably consider whether it would be possible to apply a library renaming step at this stage too. For whatever it's worth. -n _______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
