Closed luciansmith closed 5 years ago
but something in Spyder needs the dlls from mkl-2018.0.2-1 instead
We depend on Numpy to display arrays in our Variable Explorer, so that could be causing the problem here.
@mingwandroid, is there a problem with the latest MKL conda packages? Sorry to bother you, but it looks to be the case here.
No need to apologise Carlos! @msarahan is our mkl expert though, so I'm passing the buck here.
I install Miniconda3 and then run conda install pandas.. i got the same issue with mkl
Missing ordinal 242 in Miniconda3\Library\bin\mkl_intel_thread.dll
this message appear when i try to import pandas or other package
@ccordoba12 @mingwandroid @msarahan This appears to be potentially more serious than previously stated, to the point of essentially making a Anaconda environment with mkl 2018.0.3 completely unusable. I installed Spyder 3.3.0 (conda-forge) and its optional dependencies (numpy
, pandas
, matplotlib
, scipy
, sympy
and cython
) into a fresh conda environment on my on my Win 8.1 x64 system, and while import pandas
doesn't trigger the error message in that environment, anything with matplotlib
will, among other things, e.g.
import matplotlib.pyplot as plt
ax = plt.subplot(111, projection='polar')
This not only happens in Spyder, but also QtConsole, ipython, and even a bare python interpreter; each crashes with the above two lines. I also tested in another new, clean environment with just Python 3.6.6 and matplotlib installed, and got the bug immediately on import matplotlib.pyplot as plt
in the basic Python interpreter, crashing it. I then installed pandas
, and got the same bug immediately upon importing it, again crashing the interpreter. I then downgraded to mkl 2018.0.2-1 from 2018.0.3-1 with conda, and everything worked fine.
So, users can fix it relatively painlessly (for now) by just running conda install mkl=2018.0.2
under Anaconda Prompt in any affected environment. However, this would appear to be very serious for those creating a new environment that uses numpy
or other packages that depend on it, anyone running conda update --all
, or anyone installing or updating a package that triggers an install of that new version, since it will cause their environment to be essentially broken and unusable unless and until they are aware of and implement the above fix.
This is not serious in the least, conda-forge and The Anaconda Distribution
are incompatible with each other at present.
Please do not report bugs against such mixed installs until we announce full compatibility.
Is there any good reason for you to mix things like this?
So, users can fix it relatively painlessly (for now) by just running conda install mkl=2018.0.2 under Anaconda Prompt in any affected environment. However, this would appear to be very serious for those creating a new environment that uses numpy or other packages that depend on it, anyone running conda update --all, or anyone installing or updating a package that triggers an install of that new version, since it will cause their environment to be essentially broken and unusable unless and until they are aware of and implement the above fix.
None of this applies if the rules are followed. Our users are meant to pick AD or CF at present (in any given environment, in fact that's largely one of the main benefits of conda environments; mutually incompatible software (developed by different teams with different approaches to compilers and binary compatibility, and btw, we handle that stuff far better than CF does) can be ring-fenced from each other.
I installed Spyder 3.3.0 (conda-forge)
Why did you do that? Please pick one or the other for now. CF or AD, never both.
This is not serious in the least, conda-forge and
The Anaconda Distribution
are incompatible with each other at present.
Well, that sounds like a pretty serious and high-priority bug if installing one package (and a few dependencies) from CF into a supposedly "isolated" conda
environment can break an entire Anaconda install, including entirely separate, freshly created environments without any such mixing and just a small number of official AD packages. However, there may be something else going on that neither of us have considered.
Please do not report bugs against such mixed installs until we announce full compatibility.
Perhaps I misinterpret something, but not sure I understand the rationale for what I did wrong here based on the information I had available, in sharing my above observed findings on our own bug tracker on a problem affecting our own software, along with a potential workaround for our users that were experiencing an issue with the same.
Multiple users of our software apparently following reasonable good practices reported a seemingly concerning issue that affected it, which our maintainer indicated was likely with a third party, which you acknowledged above. Incidentally, I came across the same error under similar circumstances, and so followed up with a detailed further investigation of the problem that seemingly revealed it was potentially much more serious than initially thought, which in my testing affected multiple independent, freshly-created and minimal environments, and affected not only Spyder but any other Python interpreted in the environment.
While there was still a significant amount of uncertainty present (and thus I qualified my statements with "potentially", "apparently", etc) as to the nature and magnitude of the issue, given the potential for quite substantial impacts to both our own users and the wider Anaconda community, I considered it prudent to tag a couple of other individuals other participants had already named as being potentially interested parties, in case my findings were helpful in resolving the issue expeditiously. Somewhat ironically given the above statements, one of my other considerations in wanting to help head off any potential issue quickly was the number of previous problems with third-party packages outside our control that have resulted in sometimes up to dozens of bug reports (mostly not following our recommended practices) per day on our own plates that @ccordoba12 and I have had to deal with, despite our best efforts to stem the tide.
Is there any good reason for you to mix things like this?
As a matter of fact, I believe there seemed to be, at the time. As (among other things) the maintainer of Spyder's new docs, and the primary writer for the project's official blog, social media accounts, funding platforms, and other web properties, I was asked to update the former with the install and usage with Spyder for our newly independent spyder-kernels
package, and needed to grab several screenshots of the new features in action for the latter, both of which practicably necessitated actually installing the new package from somewhere.
Despite it being well over a week from the PyPI release, the defaults-channel conda
packages were still not out (the release of which we wanted the aforementioned blog post to shortly follow); pip
was not a desirable option having heard to no end of the woe which it could bring to an Anaconda install (and after helping many Spyder users pick up the pieces after its ravages), and running from a Github clone wouldn't work without a prohibitive amount of setup and configuration due to the major spyder-kernels
changes and lack of availability of that package on conda
either, not to mention the need to create a new Anaconda environment for that anyway. Therefore, protected by (what I thought was) the relative safety of an isolated, clean conda-env
, I gave installing Spyder 3.3.0 from conda-forge
a shot, fully expecting the possibility of problems and prepared to either deal with them myself, try another approach in a fresh environment, or simply wait for the official packages to do the screenshots if I had no other choice.
Indeed, was at first an immediate crash due to incompatible qt
builds, but switching that around resolved it and allowed Spyder to launch and work fine, up until the problem loading matplotlib
. I normally would have dismissed it as a result of some conda-forge
compatibility imperfection (as you did) and moved on, but I had happened to have just reviewed this issue thread in the process of starting to get back to my usual job of issue triage on this repo. Given that several other users had reported the same problem under much less questionable circumstances, and the concerning results of my consequent further investigation, it clearly seemed prudent to share my findings to make others like yourself aware in case they were indeed helping in resolving the issue, and assist our users with a potential workaround in the meantime. However, it seems you have found my concerns are not so worrisome after all, which would be be quite gratifying.
None of this applies if the rules are followed. Our users are meant to pick AD or CF at present.
As I discussed in my original report, the problem persisted across multiple fresh environments with only packages from the defaults
channel, and the CF-channel packages (which did not, I note, include mkl
or any of its related packages) were installed into a separate, isolated environment from everything else.
Why did you do that? Please pick one or the other for now. CF or AD, never both.
I'm not sure I understand why I'm being asked what appears to be the same thing twice. Are you saying I should maintain an entirely separate full Anaconda/Miniconda install just for conda-forge
packages, not to mention other channels? That would seem to negate a lot of the Anaconda's advantages with environments and channels, not to mention quite inefficient in multiple respects.
In any case, back on topic, I did several hours of rather extensive testing on another machine, this one running Windows 10 x64 (on nearly identical hardware) and with a base
Anaconda install from a roughly similar period as my other one, with some use, a handful of other packages and several conda environments present, but otherwise relatively "clean" as it mostly was used as a test machine.
I tried every procedure that produced a problem on my primary machine and several more besides (including essentially exact steps from before when I'd installed from conda-forge
)l, all in separate, fresh environments, and was never able to reproduce the error. The only other distinction I can think of between the two machines was the Win10 one was running on a non-admin account, with Anaconda installed for all users from the admin account, but no problems or other differences seemingly resulted from that (aside from the need to authenticate to install shortcuts).
Meanwhile, back on my main machine, creating several new, fresh environments again with no conda-forge
involved, and in new Anaconda prompt windows still manifests the same issues as before, unless and until the mkl
version is rolled back by one in the relevant environment.
You need to show the output from conda list --show-channel-urls
. To be clear, if I see defaults and conda-forge in that list then you need to remedy that. If you don't and see only defaults but still see this problem then report it at ContinuumIO/anaconda-issues here on github. If you see only conda-forge then I'm baffled!
This is not serious in the least, conda-forge and The Anaconda Distribution are incompatible with each other at present.
Well, that sounds like a pretty serious and high-priority bug if installing one package (and a few dependencies) from CF into a supposedly "isolated" conda environment can break an entire Anaconda install, including entirely separate, freshly created environments without any such mixing and just a small number of official AD packages. However, there may be something else going on that neither of us have considered.
If it's a high priority bug it's not a bug that anyone can do something about. conda-forge is a separate entity from AD. But that's ok, we implemented environments for that. If a package isn't on one and it's high priority then that's the issue that can be fixed here, I cannot magically make CF and AD binary compatible (and attempts to reach that stage are progressing very slowly unfortunately).
You need to show the output from
conda list --show-channel-urls
.
Like I've stated previously, I've repro'd this on my main machine in brand-new conda-envs with just python
and matplotlib
installed from defaults
—it's pretty hard to mess that up, even for me, heh. Nevertheless, here you go as an example:
(mkl-test-2) C:\Users\C. A. M. Gerlach\Documents\dev>python
Python 3.6.6 |Anaconda, Inc.| (default, Jun 28 2018, 11:27:44) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll.
(mkl-test-2) C:\Users\C. A. M. Gerlach\Documents\dev>conda list --show-channel-urls
# packages in environment at C:\Anaconda3\envs\mkl-test-2:
#
# Name Version Build Channel
blas 1.0 mkl defaults
ca-certificates 2018.03.07 0 defaults
certifi 2018.4.16 py36_0 defaults
cycler 0.10.0 py36h009560c_0 defaults
freetype 2.8 h51f8f2c_1 defaults
icc_rt 2017.0.4 h97af966_0 defaults
icu 58.2 ha66f8fd_1 defaults
intel-openmp 2018.0.3 0 defaults
jpeg 9b hb83a4c4_2 defaults
kiwisolver 1.0.1 py36h12c3424_0 defaults
libpng 1.6.34 h79bbb47_0 defaults
matplotlib 2.2.2 py36h153e9ff_1 defaults
mkl 2018.0.3 1 defaults
mkl_fft 1.0.2 py36hb217b18_0 defaults
mkl_random 1.0.1 py36h9258bd6_0 defaults
numpy 1.14.5 py36h9fa60d3_3 defaults
numpy-base 1.14.5 py36h5c71026_3 defaults
openssl 1.0.2o h8ea7d77_0 defaults
pip 10.0.1 py36_0 defaults
pyparsing 2.2.0 py36_1 defaults
pyqt 5.9.2 py36h1aa27d4_0 defaults
python 3.6.6 hea74fb7_0 defaults
python-dateutil 2.7.3 py36_0 defaults
pytz 2018.5 py36_0 defaults
qt 5.9.6 vc14h62aca36_0 defaults
setuptools 39.2.0 py36_0 defaults
sip 4.19.8 py36h6538335_0 defaults
six 1.11.0 py36_1 defaults
sqlite 3.24.0 h7602738_0 defaults
tornado 5.0.2 py36hfa6e2cd_0 defaults
vc 14 h0510ff6_3 defaults
vs2015_runtime 14.0.25123 3 defaults
wheel 0.31.1 py36_0 defaults
wincertstore 0.2 py36h7fe50ca_0 defaults
zlib 1.2.11 h8395fce_2 defaults
In the first environment it happened in, Spyder and a few of its necessary dependencies were from conda-forge
(aside from itself and spyder-kernels
, these were freetype, icu, jpeg, keyright, libpng, libsodium, pywin32-cytpes, sqlite, zeromq, and zlib
); otherwise, everything was from defaults
.
In testing this, I was unable to create a pure conda-forge
environment, even after creating and activating an empty environment, doing conda config --env --prepend channels conda-forge
then conda install -c python=3.6
and finally conda install -c matplotlib
, since several dependencies of matplotlib
, namely the offending mkl
package along with its Intel friends icc_rt
, itnel-openmp
, and the numpy
and numpy-base
that directly depended on it were all defaults
only; my guess would be due to licensing issues. That environment, interestingly, failed with a different error:
(mkl-cf) C:\Users\C. A. M. Gerlach\Documents\dev>python
Python 3.6.5 | packaged by conda-forge | (default, Apr 6 2018, 16:13:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
Traceback (most recent call last):
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\numpy\core\__init__.py", line 16, in <module>
from . import multiarray
ImportError: DLL load failed: The operating system cannot run %1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\matplotlib\__init__.py", line 127, in <module>
from . import cbook
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\matplotlib\cbook\__init__.py", line 35, in <module>
import numpy as np
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\numpy\__init__.py", line 158, in <module>
from . import add_newdocs
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\numpy\add_newdocs.py", line 13, in <module>
from numpy.lib import add_newdoc
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\numpy\lib\__init__.py", line 8, in <module>
from .type_check import *
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\numpy\lib\type_check.py", line 11, in <module>
import numpy.core.numeric as _nx
File "C:\Anaconda3\envs\mkl-cf\lib\site-packages\numpy\core\__init__.py", line 26, in <module>
raise ImportError(msg)
ImportError:
Importing the multiarray numpy extension module failed. Most
likely you are trying to import a failed build of numpy.
If you're working with a numpy git repo, try `git clean -xdf` (removes all
files not under version control). Otherwise reinstall numpy.
Original error was: DLL load failed: The operating system cannot run %1.
However, yet again, reverting to mkl
version 2018.0.2
(still on defaults
, since no conda-forge
package appears to exist) fixed the problem and worked perfectly. I again tried the same steps on my Win 10 test machine, and both versions worked just fine with no errors. Therefore, it appears to be a combination of something in my software environment (either OS or other supporting packages, or something wrong with my Anaconda install, with which I've had no serious problems until today), and that specific package version, and it appears I'm not alone.
@VELCpro can you provide the same details as the OP did with regard to your various versions and dependencies (and conda list --show-channel-urls
for the aforementioned environment) in case that helps narrow it down?
If it's a high priority bug it's not a bug that anyone can do something about. conda-forge is a separate entity from AD. But that's ok, we implemented environments for that.
Right, but to be clear as I've been stating all along, the problem with mkl 2018.0.3
occurs in multiple brand new conda
environments that have nothing to do with CF or the similarly isolated environment any of its packages are installed in. Also, if it matters, I don't have any non-defaults dependencies installed in base
(just a couple domain-specific packages from conda-forge
and a few spyder testing and development related packages from spyder-ide
, non of which shouldn't have any reverse dependencies that might actually pose a problem, nor were used or at all related to any of the above).
Anyway, its almost 7am here, so I probably should get some sleep :tired_face:
You should get some sleep, I agree!
as I've been stating all along, the problem with
mkl 2018.0.3
I've demonstrated one environment where this cannot be reproduced which includes mkl 2018.0.3
and closely resembles the details given by you.
You should get some sleep, I agree!
I've demonstrated one environment where this cannot be reproduced
Indeed; I've demonstrated an entire machine on which this cannot be reproduced. However, every one of the half-dozen environments I tested on my main machine does experience this issue on mkl 2018.0.3
, while mkl 2018.0.0
through .2
are all fine. The point I was trying to make there, was that I was experiencing the issue in multiple completely separate, all-defaults
environments, as your statements ("But that's ok, we implemented environments for that.") seemed to suggest you still thought otherwise.
Therefore, as I discussed a few paragraphs above, this seems to be either a conda bug that has resulted in something wrong with my install that has persisted across environments, or something specific to the combination of my machine and that mkl
version. To try to rule out the former, I tried to reproduce the exact series of steps used to setup the Spyder 3.3.0 conda-forge environment on my main machine as well as many other combinations besides, and trying other mkl
versions on my main machine to see if any of them also had a problem, and neither produced any error. To attempt to address the latter, my other machine where it didn't happen had nearly identical hardware and a very similar Anaconda setup, although it had Win 10 (vs. 8.1), so did at least one other reporter here, which is why I inquired of them what software environment they were trying it under. Other than that, I'd truly baffled—I'd be normally incline to dismiss it as install-specific and move on, but the clear fix (downgrading) and that fact that several other users have reported it seem to suggest further investigation is warranted.
I'm not sure what we are talking about regarding mixed installs. I just did a fresh install and then did a "conda update --all" and everything broke as people described above. Are we not supposed to update the packages ourselves? The navigator showed that there was a new version that needed updating.
This is still an issue. I just used Anaconda3-5.2.0-Windows-x86_64 (downloaded on 09/13/2018). Then did conda update --all
and spyder broke. I tried to use conda install mkl=2018.0.2
however that would involve downgrading numpy to 1.14 the original problem that I was trying to solve by updating all was to get numpy 1.15. Manually copying the dlls does not work.
spyder broke
Can you please be specific? Namely, did you experience the exact error message above, or what do you mean?
I tried to use conda install mkl=2018.0.2
What happened when you tried it? It did fix the problem, correct?
the original problem that I was trying to solve by updating all was to get numpy 1.15
Not that it necessarily contributed to this particular problem, but if you specifically, want to get NumPy 1.15, then just do conda update numpy
(or conda install numpy=1.15
).
@CAM-Gerlach Good catch, no it is not the same error, just the same cause. I failed to notice.
There are two error messages.
When I start spyder the ipython console fails to load with this traceback:
An error ocurred while starting the kernel
Traceback (most recent call last):
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\__main__.py", line 11, in
start.main()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\start.py", line 284, in main
kernel.initialize()
File "", line 2, in initialize
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\traitlets\config\application.py", line 87, in catch_config_error
return method(app, *args, **kwargs)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 474, in initialize
self.init_io()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 326, in init_io
sys.stdout.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Traceback (most recent call last):
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\__main__.py", line 11, in
start.main()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\start.py", line 284, in main
kernel.initialize()
File "", line 2, in initialize
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\traitlets\config\application.py", line 87, in catch_config_error
return method(app, *args, **kwargs)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 474, in initialize
self.init_io()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 326, in init_io
sys.stdout.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Traceback (most recent call last):
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\__main__.py", line 11, in
start.main()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\start.py", line 284, in main
kernel.initialize()
File "", line 2, in initialize
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\traitlets\config\application.py", line 87, in catch_config_error
return method(app, *args, **kwargs)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 474, in initialize
self.init_io()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 326, in init_io
sys.stdout.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Traceback (most recent call last):
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\__main__.py", line 11, in
start.main()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\start.py", line 284, in main
kernel.initialize()
File "", line 2, in initialize
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\traitlets\config\application.py", line 87, in catch_config_error
return method(app, *args, **kwargs)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 474, in initialize
self.init_io()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 326, in init_io
sys.stdout.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
Traceback (most recent call last):
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:\Users\XXXXX\Anaconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\__main__.py", line 11, in
start.main()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\spyder_kernels\console\start.py", line 284, in main
kernel.initialize()
File "", line 2, in initialize
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\traitlets\config\application.py", line 87, in catch_config_error
return method(app, *args, **kwargs)
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 474, in initialize
self.init_io()
File "C:\Users\XXXXX\Anaconda3\lib\site‑packages\ipykernel\kernelapp.py", line 326, in init_io
sys.stdout.flush()
AttributeError: 'NoneType' object has no attribute 'flush'
In the anaconda prompt from which I call spyder I see:
js: NOt allowed to load local resource: file:///C:/Users/XXXXXX/Anaconda3/lib/site-packages/spyder/utils/help/static/css/default.css
Also I note that there is no "C:/Users/XXXXXX/Anaconda3/lib" folder, when installing anaconda on Windows 10 with the Anaconda3-5.2.0-Windows-x86_64.exe the correct folder is "C:/Users/XXXXXX/Anaconda3/Lib". I'm not sure how big a deal the capital letter is, but maybe it points in the right direction.
Lastly, the numpy version 1.15 thing turned out to be something completely unrelated. I was calling python modules from Matlab, what I really needed to do was to start Matlab from Anaconda prompt so that the environment variables would be correct.
I'm reinstalling Anaconda and will not use "conda update --all" until I know this bug has been fixed.
I should also add that everytime I run Anaconda prompt I run as administrator. Also I always start spyder from within Anaconda prompt.
@jojker, your errors are unrelated with what is discussed here. The first one is fixed by downgrading ipykernel with
conda install ipykernel=4.8.2
The second one is already fixed and it'll be part of our 3.3.2 version.
The first one is fixed by downgrading ipykernel with
conda install ipykernel=4.8.2
Thanks!
Also I note that there is no "C:/Users/XXXXXX/Anaconda3/lib" folder, when installing anaconda on Windows 10 with the Anaconda3-5.2.0-Windows-x86_64.exe the correct folder is "C:/Users/XXXXXX/Anaconda3/Lib".
The Windows NTFS filesystem is case-insensitive (i.e. case does not matter), so it doesn't matter. However, it never hurts to ask like you did.
Glad you got it resolved!
A clean py3.6.6 install is broken with 2018.0.3 and 2019.0,
The ordinal 191 could not be located in the dynamic link library C:\conda\Library\bin\mkl_intel_thread.dll
2018.0.2 works. 2018 complains about ordinal 242, 2019 about 191.
e: note this is with miniconda and not the full-fat anaconda distribution.
@ccordoba12 So is there anything that can be done on our or Anaconda's side, or is it due to some specific user-side action?
We can't do anything about this in Spyder. It has to be fixed in Anaconda.
Would it be helpful to file a bug report for Anaconda? Is there already one?
It may be helpful to install a different Visual Studio runtime. We have had some reports that installing the VS 2013 runtime helps.
conda install vs2013_runtime
The problem exists when no Visual Stuido runtime is installed at all. Are you suggesting that installing it will fix the problem?
Try it?
@msarahan @mingwandroid @ccordoba12 I had a Python 3.6, all-Anaconda defaults
channel environment on Windows 8.1 x64 and conda 4.5.11
for running the current master
of Spyder 4, which had only Spyder's dependencies (and nothing else) installed under Python 3.6, and of course everything worked. However, when I ran conda install matplotlib
, which generated the following output:
Solving environment: done
## Package Plan ##
environment location: C:\Anaconda3\envs\spyder-4-lsp
added / updated specs:
- matplotlib
The following packages will be downloaded:
package | build
---------------------------|-----------------
mkl_fft-1.0.6 | py36hdbbee80_0 120 KB
blas-1.0 | mkl 6 KB
numpy-base-1.15.2 | py36h8128ebf_0 3.9 MB
numpy-1.15.2 | py36ha559c80_0 48 KB
matplotlib-3.0.0 | py36hd159220_0 6.7 MB
------------------------------------------------------------
Total: 10.8 MB
The following NEW packages will be INSTALLED:
blas: 1.0-mkl
cycler: 0.10.0-py36h009560c_0
freetype: 2.9.1-ha9979f8_1
icc_rt: 2017.0.4-h97af966_0
intel-openmp: 2019.0-118
kiwisolver: 1.0.1-py36h6538335_0
matplotlib: 3.0.0-py36hd159220_0
mkl: 2019.0-118
mkl_fft: 1.0.6-py36hdbbee80_0
mkl_random: 1.0.1-py36h77b88f5_1
numpy: 1.15.2-py36ha559c80_0
numpy-base: 1.15.2-py36h8128ebf_0
The following packages will be UPDATED:
certifi: 2018.8.13-py36_0 --> 2018.8.24-py36_1
I then started Spyder (via boostrap.py
) and it immediately crashed with the following dialog:
and output (before it didn't get to print any of the usual startup messages, except fort the very first print statement we have at the beginning of the script, and none of the others immediately after):
Executing Spyder from source checkout
Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll.
I then tried the following, all of which had no effect:
conda install -f mkl
conda install vs2013_runtime
as you suggested, conda update --all
, after this was all doneTherefore, I am uncertain on how to proceed.
where mkl_core.dll
outputs
C:\Anaconda3\envs\spyder-4-lsp\Library\bin\mkl_core.dll
C:\Anaconda3\Library\bin\mkl_core.dll
where mkl_intel_thread.dll
outputs
C:\Anaconda3\envs\spyder-4-lsp\Library\bin\mkl_intel_thread.dll
C:\Anaconda3\Library\bin\mkl_intel_thread.dll
conda list mkl
outputs
# Name Version Build Channel
mkl 2019.0 118
mkl_fft 1.0.6 py37hdbbee80_0
mkl_random 1.0.1 py37h77b88f5_1
Thanks!
That's pretty confusing. When you run spyder's bootstrap.py, do you have the env activated? If not, it may be falling through to the root env, which may have an older, out-of-date mkl. What are the versions of mkl-related stuff in the root env?
Maybe spyder's way of subprocessing or something is escaping the activated env somehow? Can you try:
When you run spyder's bootstrap.py, do you have the env activated? If not, it may be falling through to the root env, which may have an older, out-of-date mkl. What are the versions of mkl-related stuff in the root env?
@msarahan Thanks for your quick response. I considered something like that at first, but the fact that the environment was activated, the first entry on both where
calls was the correct dll
from the environment (whereas if environment activation fails for some reason, silently or not, where
will only return the base
path), and most importantly the path listed on the actual error dialog was to the environment's copy of the dll
(that existed and was the correct, signed and verified version 2019.0), it seemed very unlikely. I also tested it in a fresh, stock Anaconda prompt and also had the same negative result. EDIT: Further results make this possibility yet more unlikely; see below
In my base env I have the same versions of mkl_random
, mkl-service
, blas
, and icc_rt
(as well as cycler
and kiwisolver
), and after downgrading and restesting, the same version of matplotlib
(2.2.2) and intel-openmp
(2018.0.0). The closest I was able to get mkl
itself was 2018.0.3 (the version with hte first reported problems above and elsewhere) vs 2018,0.2 in base, and mkl_fft 1.0.2 vs. 1.0.1, due to limited availability of Python 3.7 builds. I couldn't go further without downgrading back to 3.6 (and I was trying to test Python 3.7 after all); similarly, I could only get numpy 1.14.5 (vs 1.13.3) and numpy-base
1.14.5 (vs. 1.14.3).
However, I can just go ahead and downgrade my test env back to 3.6 the exact same versions of those packages (plus numpy, matplotlib, etc for a good measure) and see if the problem reoccurs. If it does not, that would narrow it down to either a problem with mkl >=2018.0.3 / mkl_fft >=1.0.2 / numpy >1.14.3, or an issue like that you describe, with versions somewhat still falling through to the incorrect ones, which can be further investigated by alternatively upgrading DONE, see belowbase
and the test env and testing the results.
EDIT: Okay, so downgrading those 4 packages (plus Python to 3.6) did indeed get things working again. I will now try upgrading each of them to their previous versions, to try to isolate the culprit(s), Once I find it/them, I will upgrade my base env to match and see if it resolves anything. DONE, see below
Also, the call that triggers the error must be happening between line 75 and line 123 of bootstrap.py, given the print statements on those respective lines. However, there are no obvious culprits that would be calling anything outside the Refined further; see below.os
module of the standard library, except for get_git_revision
and its spyder.utils.vcs
module on the line before and at the print statement on 123.
@msarahan Okay, so updating numpy
to 1.14.3 in base
and the test env still worked, but updating it and numpy-base
to 1.14.4 required a later version of mkl
, as did updating mkl_fft
. Updating just mkl
to 2018.0.3
did not result in this specific error and the consequent Spyder crash, and nor did updating mkl_fft
to 1.0.2. However, updating numpy
and numpy-base
to 1.14.4 (from 1.14.3) was the culprit (and it continued to occur even if mkl_fft
was downgraded back to 1.0.1.
Then, I updated base
to numpy
and numpy-base
1.14.4, which also updated mkl
to 2018.0.3 but nothing else. Then, still in base
, upon attempting to launch spyder
3,3,1 release version from the normal conda package that had always worked previously, I indeed get the same error, which is also still the case from my test env with the same versions. Therefore, the one common factor in the error is NumPy (and numpy-base
) >=1.14.4, while the error does not occur with <=1.14.3 of both, regardless of environment. Downgrading just numpy
and numpy-base
in base (and the test env) to 1.14.3 again made that particular error disappear in the respective environment.
With mkl at 2018.0.3 and numpy/numpy base at 1.14.3 in both base and my test env (and every aforementioned package at identical versions too), launching Spyder 4 latest master
in my test environment and Spyder 3.3.1 in base
didn't produce the error dialog at first and crash, but Spyder 4 in the test env did produce it much later in the startup process (perhaps at the attempted automatic import of matplotlib
somewhere) and continued loading normally. For both, the console started fine, as did running import numpy as np
and some basic numpy functions (e.g.test_array = np.array([4, 3, 2, 3])
).
After running import matplotlib.pyplot as plt
(which did not display an error), I ran plt.plot(test_array)
or plt.plot([3, 2, 3, 4])
on both and got the Ordinal 241
error dialog yet again, and the kernel also crashed, displaying simply b''
as the An error occurred while starting the kernel
message on Spyder 4 and Kernel died, restarting
with a successful auto restart on Spyder 3/base. Installing mkl
2018.0.2 on each env in turn resolved those issues on their respective envs, while the versions of each had no effect on the other. However, these versions of numpy and mkl are not available for Python 3.7 (the last such versions of each, in fact), thus preventing this being a viable solution even as a band-aid.
Anyway, the specific line in bootstrap.py that triggers the error is indeed from spyder.utils.vcs import get_git_revision
, in turn, the line there is from spyder.utils import programs
, which drilling further implicates the line from spyder.config.utils import is_anaconda
, in turn calling the failing line spyder_kernels.utils import iofuncs
. This file, then, is the ultimate culprit.
Barring the unlikely possibility the error is triggered at from spyder_kernels.py3compat import getcwd, pickle, PY2, to_text_string
, the offending line is very probably 158, import numpy as np
, as it actually executes at import time while the remaining scipy
-related code not inside a def
block does not, because scipy
is not installed in the environment and thus the rest of the block would be skipped.
Does this help any?
@msarahan @mingwandroid Thanks for your help so far. Any progress on this? Is there anything more you need from me or that I can otherwise do to help?
Now ``conda install numpy-base-1.14.3 numpy=1.14.3 isn't even available under python=3.7 even with mkl 2018.0.3. This issue is utterly crippling to my ability to test and develop Spyder under Python 3.7 and Anaconda, since under Python 3.7 I can't even run the test suite locally nor do anything numpy/pandas/matplotlib/etc. related, which is a large part of Spyder's functionality, and I've done everything I and everyone else could think of to rule out user error or an issue with my environment, short of a full on clean re-install that would require hours upon hours of time, effort and disruption to download, install and setup my environments again and I hope to avoid if at all possible.
Looking forward to hearing further. Thanks!
@aperchak reported another instance of the issue on our Gitter:
I'm having a problem launching Spyder 3 - getting the error message: "The ordinal 242 could not be located in the dynamic link library". I searched a bit around the web and I understand this has something to do with a new update? I could swear it worked just the other day. Any solutions to that? I'm just taking my first steps in Python.
I'm using Windows 10.0 build 17134, and Anaconda 5.3, Python 3.7, in 64-bit - the most recent one available on anaconda.com/download.
I instructed them to run conda install numpy=1.14.3 numpy-base=1.14.3 mkl=2018.0.2
and they responded
I tried the command, and although Spyder now loads up and seems to be operating fine, a new error has popped up upon launching - "The procedure entry point mkl_blas_dgem2vu could not be located in the dynamic link library". I did notice some error string upon typing "import matplotlib", which is required for my Intro to Python course.
This closely parallels what I observed above, when I had 2018.0.3 installed alongside numpy 1.14.3 .
Hi all. Just prefacing that to say I'm a novice would be an understatement. I downloaded the most recent version available on anaconda.com/download (Anaconda 5.3, Python 3.7, in 64-bit) on a PC of mine, and Spyder is launching without any error messages. This to contrast an installation on a different PC where I'm receiving the error messages described here (ordinal 242...). Both versions were installed cleanly, both on the same Windows 10.0 17134 build. I've included the conda list
output from the working version:
Is there any way I could be of help in supplying info from the working version? Both Anaconda's were installed cleanly, from the direct link, and involved no steps in between the moment of download to the moment of launching Spyder. On one PC Spyder is working, on another Spyder pops the 'ordinal 242' error message and fails to launch. Thank you.
Do you have any (non-Metro UI) applications, drivers, utilities etc. installed on one machine and not the other? Its possible that the dlls could conflict. In particular, the program "Amplitube" was reported to have caused this over on the Anaconda issue, ContinuumIO/anaconda-issues#8561 .
Also, please post a screenshot or the full exact error message, and the output of where mkl_core.dll
and where mkl_intel_thread
in the environment in which you're trying to run Spyder (e.g. base
by default, if you're running it from the shortcut).
Further, you can try the following:
conda install vs2013_runtime
conda install anaconda=5.3
conda install python=3.6
conda create -n spyder-test-env python=3
, activate
it, then install Spyder with conda install spyder
.@aperchak informed us that they indeed have "Amplitude" installed on the suspect machine, so its almost certainly that for their case per ContinuumIO/anaconda-issues#8561 .
Good old amplitude! We need to figure out a way around this..
I tried reporting this to ik multimedia, but they just offered a work around. I wanted them to change their installation.
Get Outlook for Androidhttps://aka.ms/ghei36
From: Ray Donnelly notifications@github.com Sent: Wednesday, October 24, 2018 7:36:18 PM To: spyder-ide/spyder Cc: bigcatz; Comment Subject: Re: [spyder-ide/spyder] Clean conda Windows install, followed by 'conda update --all' results in wrong mkl dlls being used for Spyder (#7357)
Good old amplitude! We need to figure out a way around this..
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/spyder-ide/spyder/issues/7357#issuecomment-432873588, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Am2qUzAlfuFGyj8-cv-zX64iAkUT1pTsks5uoQeCgaJpZM4U5AJU.
they just offered a work around.
What did they suggest?
@mingwandroid Indeed; thanks for your attention to this problem. Unfortunately, for both my own case and other users on the Anaconda thread, Amplitude is not installed and in fact a search revealed no files with mkl
in the name anywhere inside the entire Windows
directory; where
can't find any other mkl
-related dlls on my path, this can be reproduced in multiple clean environments (including base
, and in environments with the same versions of everything) and throughout extensive testing, and I've tried everything suggested short of a complete reinstall without anything fixing it, other than the procedure described above (downgrading numpy, mkl, etc)—and even that only now appears to work on Python 3.6, not 3.7 due to unavailability of packages.
So yeah, Amplitude was definitely the culprit here too as I uninstalled the software and the error was gone. I even reinstalled Amplitude thereafter and the error message popped again. Said error:
As per request, I ran the where
commands before uninstalling Ampltiude and after.
With Amplitude:
Without Amplitude:
There seems to be a duplication of the files with Amplitude installed, but I'll leave it to you experts to decipher what's that all about.
Thanks for the help.
Hello everyone, I keep on running into exactly the same issue after installing Anaconda 3 on my old Windows 10 machine. Already tried everything but keep on getting "The ordinal 242 was not found in the DLL []", as soon as I try to run any code that imports numpy in my jupyter notebook.
I already tried the above mentioned where commands to see where my mkl_core.dll and mkl_intel_thread.dll where located and got this:
Any help would be greatly appreciated as I really need to be able to import numpy for a course I am currently taking! Thanks a lot for the help.
@janm97 Did you try conda install mkl=2018.0.2
?
@CAM-Gerlach Thanks a lot! That fixed it.
We have spoken with Intel about this issue. They said that there are some backwards incompatible changes in mkl 2019. We had been operating under the assumption that software built against 2018 would work with 2019, but that is not necessarily true. We will be rebuilding packages so that constraints are more accurate, and so thata complete set of software built with mkl 2019 is available.
How did this get through testing? Can we figure that out?
We will be rebuilding packages so that constraints are more accurate, and so thata complete set of software built with mkl 2019 is available.
Great news Mike!! Thanks for the followup.
Problem Description
A clean conda install from https://www.anaconda.com/download/#windows (version 5.2.0) works for Spyder, but if I then do a 'conda update --all', the resulting configuration is broken. When you run Spyder, launching from Anaconda navigator, you get a message about a missing ordinal 242 in Anaconda3\Library\bin\mkl_intel_thread.dll
This turns out to be because the dlls from mkl-2018.0.3-1 are installed in Anaconda3\Library\bin\, but something in Spyder needs the dlls from mkl-2018.0.2-1 instead. If you copy the dlls from Anaconda3\pkgs\mkl-2018.0.2-1\Library\bin into Anaconda3\Library\bin, Spyder then launches normally. (This probably breaks something else, but if so, it's something I haven't yet tried to use ;-)
What steps reproduce the problem?
What is the expected output? What do you see instead?
Paste Traceback/Error Below (if applicable)
Versions
Dependencies