libgfortran broken? #686
Comments
|
Am able to work around this on my local machine by pre-loading the system level libgfortran, bypassing the anaconda provided one:
Seems like the the anaconda libgfortran just needs rebuilt with the "proper" compiler? Please advise... |
|
I just came across this as well. The "fix" that I worked up for now was to revert to scipy to 0.16.0. I also found that bypassing the Broken: |
|
@basnijholt, you may be interested in following this issue. |
|
@jakirkham thank you! 👍 I build a package that also depends on Then I tried to force the package to depend on This is a problem on Binder for example, where a Docker image is generated from an |
|
So, maybe you could suggest to the Binder maintainers that they update to a newer version of In the interim, you could add some hacky steps in your notebook in the beginning to fix Alternatively, Binder let's you use Docker. So, you could write a Of the two options, adding hacky steps with |
|
I already asked the Binder guys to update conda, and they will do it :) |
This (or a similar) issue is causing ReadTheDocs and Binder to fail in importing scipy when using conda envs: readthedocs/readthedocs.org#2074 The error is triggered when importing For the full RTD logs see http://readthedocs.org/projects/fretbursts/builds/3813468/ Binder images containing scipy are created correctly but then importing |
|
@tritemio You're fixing the bugfix releases and even the build numbers for the packages. You can either specify libgfortran=1.0 as well, or you can use the latest builds. Either one will work. |
|
Rebuilding with EDIT: there also is a dependency on |
|
I wonder if the |
|
I don't know if it is of help for anyone, but the build of kwant that works fine with Maybe this gives a clue to someone with more knowledge in this area. |
|
@insertinterestingnamehere, thanks. Yes the problem was that I generated the environment file on os x and used it on linux. A given combination of anaconda packages may have different bugs on different platforms and the build number are increased independently in order to fix build issued such as the one here. Note to self: it is a good idea to remove the build number from the environment files in order to avoid this kind of issues. |
|
I have a similar issue with the asssimulo package and scipy 0.17 on python 3.4. The tip from swryan helped. |
|
I had a similar problem. And also the annoying message saying that the license of mkl was about to expire. In my case this was solved updating conda to 4.0. After that numpy and scypi were also updated to: |
|
It so happens that the conda libgcc package contains a good libgfortran.so.3 file, with the 1.4 symbols defined: So if I only have libgcc, I can However after installing lingfortran, I get an older version without those symbols: This is behaviour breaks packages that build well with libgcc, because the libffortran overwrites the more modern version of the .so, such as this: https://github.com/Zaharid/conda-recipes/tree/master/apfel Would be grateful if this could be fixed soon. |
|
A workaround seems to be simply: |
|
+1 |
|
This may be related. I just downloaded and installed Anaconda 4.0.0. Then did conda install gcc. The gcc and g++ versions are as expected the conda version 4.8.5. However, gfortran is now using version 4.9.2, which is my native gfortran compiler on my ubuntu 15.04. If I'm doing which gfortran, the answer is still ~/anaconda2/bin/gfortran though. With Anaconda 2.5.0 the conda install gcc gives me as expected gfortran version 4.8.5. |
|
I just encountered this and @Zaharid's work-around solved my problem. |
|
Great! But, where can I find it, I don't see it on the anaconda channel, nor on your channel. |
|
Also, I should add that my update is a short-term band-aid. We are trying to figure out how to capture build requirements better at build time - so things like the GFORTRAN_1.x as well as package version numbers. That will be necessary to fix these kinds of issues long-term. |
|
Should be in the default channel, let me make sure... I see it as: The last one is the "good" one |
|
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgfortran.so.3 works for me. |
|
Just did a fresh install. Unfortunately |
|
Any update on this? I tried removing and installing This is my package info: |
|
Numpy 1.9 was not correctly pinned to libgfortran version 1. conda install -f libgfortran==1 should make things work again. @ilanschnell, can you alter numpy 1.9's metadata to reflect this dependency/pinning? |
|
@msarahan I ended up re-installing conda, I read this message after re-installation :( Thank you for your reply. I have to say, I did try Thanks again, |
|
The critically important part is not the --force, but the ==1 part. The latest libgfortran package is version 3, which is not compatible with numpy 1.9. Thus, you must manually tell it to install the older version. |
|
I ran into this today too. Any idea when it will be fixed? The workaround is nice but users still get tripped up. |
|
I was about to release new binaries for our package (Sherpa, the modeling package of the Chandra X-Ray telescope software) when I realized the binaries I had been testing were broken by an update in libgcc at the build number level. libgcc 4.8.5-1 contained libgfortran, while 4.8.5-2 does not. This is a big change for a build number increase, and I am not sure how to proceed. Should I pin libgcc 4.8.5 to build number 1 hoping this doesn't collide with other packages user may have? Or should I assume that libgfortran has been fixed (which doesn't seem to be the case as libgfortran hasn't been updated)? |
|
libgcc 5.2 is backwards compatible with binaries built with gcc 4.8. Using the newer version should work. That aside, pulling libgfortran out in a new build seems wrong to me. I'm not sure on what the rationale could have been for that. |
|
Thanks @insertinterestingnamehere. Whatever the rationale, I was rather surprised by the fact that such a big change was introduced in a build number increase. Should I start pinning down dependencies at the build number level? |
|
A bug in the libgfortran package for at least a decade, see https://bugzilla.redhat.com/show_bug.cgi?id=191497 .I usually patch this by creating the symbolic link (as root) fi |
|
With the Anaconda-5 series of packages, we're building with gcc 7.2, which finally bumps the gfortran version - it's .so.4 now. I think this issue is solved. Note: the old gcc package (4.8.*) is incompatible with the new packages, and should not be mixed with them. Prefer the new compilers instead. We have docs on doing that at https://www.anaconda.com/blog/developer-blog/utilizing-the-new-compilers-in-anaconda-distribution-5/ |
Started getting this error a couple days ago:
ImportError: /home/travis/miniconda/lib/python2.7/site-packages/scipy/special/../../../../libgfortran.so.3: versionGFORTRAN_1.4' not found (required by /usr/lib/liblapack.so.3gf)`It seems coincident with the latest update to libgfortran:
https://anaconda.org/anaconda/libgfortran/files
Would appreciate any insight into what the issue is and more importantly, what the fix is:
https://travis-ci.org/OpenMDAO/OpenMDAO/jobs/114269055
Thanks!
The text was updated successfully, but these errors were encountered: