libgfortran=3.0 should not be install with numpy <= 1.9

[jreback]

libgfortran=1.0 works just fine, but since libgfortran=3.0 just came out, its not compatible with older numpies (using 1.8.1 here), see here.

So this totally breaks on ubuntu.

jreback@ubuntu:~/pandas3.4$ conda create -n test python=3.4 numpy=1.8.1 libgfortran --dry
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ......
Solving package specifications: ............
Package plan for installation in environment /home/jreback/miniconda/envs/test:

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    numpy-1.8.1                |           py34_0         7.2 MB

The following NEW packages will be INSTALLED:

    libgfortran: 3.0-0        
    numpy:       1.8.1-py34_0 
    openssl:     1.0.2g-0     
    pip:         8.0.3-py34_0 
    python:      3.4.4-0      
    readline:    6.2-2        
    setuptools:  20.1.1-py34_0
    sqlite:      3.9.2-0      
    tk:          8.5.18-0     
    wheel:       0.29.0-py34_0
    xz:          5.0.5-1      
    zlib:        1.2.8-0      

Dry run: exiting
jreback@ubuntu:~/pandas3.4$ 

cc @ilanschnell @msarahan @mcg1969

[zym1010]

same problem. tried numpy 1.9.3 without MKL and failed just upon importing.

(test3)yimengzh_everyday@leelabgpu:~$ miniconda2/bin/conda create --name test4 python nomkl numpy=1.9
Fetching package metadata: ....
Solving package specifications: ...............
Package plan for installation in environment /home/yimengzh_everyday/miniconda2/envs/test4:

The following NEW packages will be INSTALLED:

    libgfortran: 3.0-0
    nomkl:       1.0-0
    numpy:       1.9.3-py27_nomkl_1 [nomkl]
    openblas:    0.2.14-4
    openssl:     1.0.2g-0
    pip:         8.0.3-py27_0
    python:      2.7.11-0
    readline:    6.2-2
    setuptools:  20.1.1-py27_0
    sqlite:      3.9.2-0
    tk:          8.5.18-0
    wheel:       0.29.0-py27_0
    zlib:        1.2.8-0

Proceed ([y]/n)? y

Linking packages ...
[      COMPLETE      ]|######################################################################################################################| 100%
#
# To activate this environment, use:
# $ source activate test4
#
# To deactivate this environment, use:
# $ source deactivate
#
(test3)yimengzh_everyday@leelabgpu:~$ source activate test4
discarding /home/yimengzh_everyday/miniconda2/envs/test3/bin from PATH
prepending /home/yimengzh_everyday/miniconda2/envs/test4/bin to PATH
(test4)yimengzh_everyday@leelabgpu:~$ python -c "import numpy; numpy.test()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/yimengzh_everyday/miniconda2/envs/test4/lib/python2.7/site-packages/numpy/__init__.py", line 170, in <module>
    from . import add_newdocs
  File "/home/yimengzh_everyday/miniconda2/envs/test4/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in <module>
    from numpy.lib import add_newdoc
  File "/home/yimengzh_everyday/miniconda2/envs/test4/lib/python2.7/site-packages/numpy/lib/__init__.py", line 18, in <module>
    from .polynomial import *
  File "/home/yimengzh_everyday/miniconda2/envs/test4/lib/python2.7/site-packages/numpy/lib/polynomial.py", line 19, in <module>
    from numpy.linalg import eigvals, lstsq, inv
  File "/home/yimengzh_everyday/miniconda2/envs/test4/lib/python2.7/site-packages/numpy/linalg/__init__.py", line 51, in <module>
    from .linalg import *
  File "/home/yimengzh_everyday/miniconda2/envs/test4/lib/python2.7/site-packages/numpy/linalg/linalg.py", line 29, in <module>
    from numpy.linalg import lapack_lite, _umath_linalg
ImportError: libgfortran.so.1: cannot open shared object file: No such file or directory

[zym1010]

currently, I guess a simple solution is to specify libgfortran=1 in conda install.

seems to me recently these kinds of problems appear pretty often... can Continuum Analytics be more strict on QA? I'd like to pay some fee for quality bundles, instead of compiling everything myself...

[ilanschnell]

numpy 1.8.1 did not explicitly list libgfortran as a dependency, but 1.8.2 does:

$ conda create -n test python=3.4 numpy=1.8.2

works fine for me.

[jreback]

thanks @zym1010 updated to be <= 1.9 (we had a CI run that specifically tested with 1.8.1)

[jreback]

ahh, ok @ilanschnell thanks.

[ilanschnell]

Better, just say:

$ conda create -n test python=3.4 numpy=1.8

[jreback]

yeah, I had this hard-coded in the CI, so just left it. Looks ok now that I fixed the libgfortran=1.0

thanks @ilanschnell

[zym1010]

@ilanschnell seems that it's still broken for 1.9?

[mcg1969]

Unless there is a reason to believe this is the solver's fault---and not faulty metadata---this isn't something I can fix. Leave it to the metadata manipulators ;-)

[insertinterestingnamehere]

It looks like we're missing a build of scipy 0.16.1 with the latest bugfix release of numpy 1.9. That's causing an older build of scipy to get pulled in by the solver. See scipy/scipy#5917 (comment).

The 1.9 failure here is specific to the nomkl package. Getting a build of that one with the newer libgfortran should fix it.

[ilanschnell]

I've updated numpy 1.9 as well as scipy 0.17.0 np19 to link against libgfortran 3.0.

[tritemio]

This (or a similar) issue is causing RTD to fail in importing scipy when using conda envs: readthedocs/readthedocs.org#2074

The error is triggered when importing scipy.stats:

ImportError: libgfortran.so.1: cannot open shared object file: No such file or directory

See the RTD issue for full logs.

[dprada]

@tritemio In my case this was solved updating conda to 4.0. After that numpy and scypi were also updated to:

    numexpr:      2.4.4-np110py27_p0  [mkl] --> 2.5-np110py27_0   
    numpy:        1.10.2-py27_p0      [mkl] --> 1.10.4-py27_1     
    pytables:     3.2.2-np110py27_0   --> 3.2.2-np110py27_1 
    scikit-learn: 0.17-np110py27_p1   [mkl] --> 0.17.1-np110py27_0
    scipy:        0.16.1-np110py27_p0 [mkl] --> 0.17.0-np110py27_2

[github-actions]

Hi there, thank you for your contribution to Conda!

This issue has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue if needed.