Closed luciansmith closed 5 years ago
ccordoba12
commented
6 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.
mingwandroid
commented
6 years ago No need to apologise Carlos! @msarahan is our mkl expert though, so I'm passing the buck here.
VELCpro
commented
6 years ago 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
CAM-Gerlach
commented
6 years ago @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.
mingwandroid
commented
6 years ago 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?
mingwandroid
commented
6 years ago 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.
mingwandroid
commented
6 years ago 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.
CAM-Gerlach
commented
6 years ago This is not serious in the least, conda-forge and
The Anaconda Distributionare 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.
CAM-Gerlach
commented
6 years ago 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.
CAM-Gerlach
commented
6 years ago 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.
CAM-Gerlach
commented
6 years ago 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.
mingwandroid
commented
6 years ago 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!
mingwandroid
commented
6 years ago 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).
CAM-Gerlach
commented
6 years ago 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 defaultsIn 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?
CAM-Gerlach
commented
6 years ago 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:
mingwandroid
commented
6 years ago 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.
CAM-Gerlach
commented
6 years ago 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.0through .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.
bigcatz
commented
6 years ago 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.
jojker
commented
5 years ago 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.
CAM-Gerlach
commented
5 years ago 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).
jojker
commented
5 years ago @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.
ccordoba12
commented
5 years ago @jojker, your errors are unrelated with what is discussed here. The first one is fixed by downgrading ipykernel with
conda install ipykernel=4.8.2The second one is already fixed and it'll be part of our 3.3.2 version.
jojker
commented
5 years ago The first one is fixed by downgrading ipykernel with
conda install ipykernel=4.8.2
Thanks!
CAM-Gerlach
commented
5 years ago 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!
brandondube
commented
5 years ago 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.
CAM-Gerlach
commented
5 years ago @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?
ccordoba12
commented
5 years ago We can't do anything about this in Spyder. It has to be fixed in Anaconda.
luciansmith
commented
5 years ago Would it be helpful to file a bug report for Anaconda? Is there already one?
msarahan
commented
5 years ago 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
luciansmith
commented
5 years ago The problem exists when no Visual Stuido runtime is installed at all. Are you suggesting that installing it will fix the problem?
msarahan
commented
5 years ago Try it?
CAM-Gerlach
commented
5 years ago @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_1I 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 mklconda 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.dllwhere mkl_intel_thread.dll outputs
C:\Anaconda3\envs\spyder-4-lsp\Library\bin\mkl_intel_thread.dll
C:\Anaconda3\Library\bin\mkl_intel_thread.dllconda list mkl outputs
# Name Version Build Channel
mkl 2019.0 118
mkl_fft 1.0.6 py37hdbbee80_0
mkl_random 1.0.1 py37h77b88f5_1Thanks!
msarahan
commented
5 years ago 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:
CAM-Gerlach
commented
5 years ago 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.
CAM-Gerlach
commented
5 years ago @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?
CAM-Gerlach
commented
5 years ago @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!
CAM-Gerlach
commented
5 years ago @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 .
aperchak
commented
5 years ago 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: # Name Version Build Channel
_ipyw_jlab_nb_ext_conf 0.1.0 py37_0
alabaster 0.7.11 py37_0
anaconda 5.3.0 py37_0
anaconda-client 1.7.2 py37_0
anaconda-navigator 1.9.2 py37_0
anaconda-project 0.8.2 py37_0
appdirs 1.4.3 py37h28b3542_0
asn1crypto 0.24.0 py37_0
astroid 2.0.4 py37_0
astropy 3.0.4 py37hfa6e2cd_0
atomicwrites 1.2.1 py37_0
attrs 18.2.0 py37h28b3542_0
automat 0.7.0 py37_0
babel 2.6.0 py37_0
backcall 0.1.0 py37_0
backports 1.0 py37_1
backports.shutil_get_terminal_size 1.0.0 py37_2
beautifulsoup4 4.6.3 py37_0
bitarray 0.8.3 py37hfa6e2cd_0
bkcharts 0.2 py37_0
blas 1.0 mkl
blaze 0.11.3 py37_0
bleach 2.1.4 py37_0
blosc 1.14.4 he51fdeb_0
bokeh 0.13.0 py37_0
boto 2.49.0 py37_0
bottleneck 1.2.1 py37h452e1ab_1
bzip2 1.0.6 hfa6e2cd_5
ca-certificates 2018.03.07 0
certifi 2018.8.24 py37_1
cffi 1.11.5 py37h74b6da3_1
chardet 3.0.4 py37_1
click 6.7 py37_0
cloudpickle 0.5.5 py37_0
clyent 1.2.2 py37_1
colorama 0.3.9 py37_0
comtypes 1.1.7 py37_0
conda 4.5.11 py37_0
conda-build 3.15.1 py37_0
conda-env 2.6.0 h36134e3_1
console_shortcut 0.1.1 3
constantly 15.1.0 py37h28b3542_0
contextlib2 0.5.5 py37_0
cryptography 2.3.1 py37h74b6da3_0
curl 7.61.0 h7602738_0
cycler 0.10.0 py37_0
cython 0.28.5 py37h6538335_0
cytoolz 0.9.0.1 py37hfa6e2cd_1
dask 0.19.1 py37_0
dask-core 0.19.1 py37_0
datashape 0.5.4 py37_1
decorator 4.3.0 py37_0
defusedxml 0.5.0 py37_1
distributed 1.23.1 py37_0
docutils 0.14 py37_0
entrypoints 0.2.3 py37_2
et_xmlfile 1.0.1 py37_0
fastcache 1.0.2 py37hfa6e2cd_2
filelock 3.0.8 py37_0
flask 1.0.2 py37_1
flask-cors 3.0.6 py37_0
freetype 2.9.1 ha9979f8_1
get_terminal_size 1.0.0 h38e98db_0
gevent 1.3.6 py37hfa6e2cd_0
glob2 0.6 py37_0
greenlet 0.4.15 py37hfa6e2cd_0
h5py 2.8.0 py37h3bdd7fb_2
hdf5 1.10.2 hac2f561_1
heapdict 1.0.0 py37_2
html5lib 1.0.1 py37_0
hyperlink 18.0.0 py37_0
icc_rt 2017.0.4 h97af966_0
icu 58.2 ha66f8fd_1
idna 2.7 py37_0
imageio 2.4.1 py37_0
imagesize 1.1.0 py37_0
incremental 17.5.0 py37_0
intel-openmp 2019.0 118
ipykernel 4.10.0 py37_0
ipython 6.5.0 py37_0
ipython_genutils 0.2.0 py37_0
ipywidgets 7.4.1 py37_0
isort 4.3.4 py37_0
itsdangerous 0.24 py37_1
jdcal 1.4 py37_0
jedi 0.12.1 py37_0
jinja2 2.10 py37_0
jpeg 9b hb83a4c4_2
jsonschema 2.6.0 py37_0
jupyter 1.0.0 py37_7
jupyter_client 5.2.3 py37_0
jupyter_console 5.2.0 py37_1
jupyter_core 4.4.0 py37_0
jupyterlab 0.34.9 py37_0
jupyterlab_launcher 0.13.1 py37_0
keyring 13.2.1 py37_0
kiwisolver 1.0.1 py37h6538335_0
lazy-object-proxy 1.3.1 py37hfa6e2cd_2
libcurl 7.61.0 h7602738_0
libiconv 1.15 h1df5818_7
libpng 1.6.34 h79bbb47_0
libsodium 1.0.16 h9d3ae62_0
libssh2 1.8.0 hd619d38_4
libtiff 4.0.9 h36446d0_2
libxml2 2.9.8 hadb2253_1
libxslt 1.1.32 hf6f1972_0
llvmlite 0.24.0 py37h6538335_0
locket 0.2.0 py37_1
lxml 4.2.5 py37hef2cd61_0
lzo 2.10 h6df0209_2
m2w64-gcc-libgfortran 5.3.0 6
m2w64-gcc-libs 5.3.0 7
m2w64-gcc-libs-core 5.3.0 7
m2w64-gmp 6.1.0 2
m2w64-libwinpthread-git 5.0.0.4634.697f757 2
markupsafe 1.0 py37hfa6e2cd_1
matplotlib 2.2.3 py37hd159220_0
mccabe 0.6.1 py37_1
menuinst 1.4.14 py37hfa6e2cd_0
mistune 0.8.3 py37hfa6e2cd_1
mkl 2019.0 118
mkl-service 1.1.2 py37hb217b18_5
mkl_fft 1.0.4 py37h1e22a9b_1
mkl_random 1.0.1 py37h77b88f5_1
more-itertools 4.3.0 py37_0
mpmath 1.0.0 py37_2
msgpack-python 0.5.6 py37he980bc4_1
msys2-conda-epoch 20160418 1
multipledispatch 0.6.0 py37_0
navigator-updater 0.2.1 py37_0
nbconvert 5.4.0 py37_1
nbformat 4.4.0 py37_0
networkx 2.1 py37_0
nltk 3.3.0 py37_0
nose 1.3.7 py37_2
notebook 5.6.0 py37_0
numba 0.39.0 py37h830ac7b_0
numexpr 2.6.8 py37h9ef55f4_0
numpy 1.15.1 py37ha559c80_0
numpy-base 1.15.1 py37h8128ebf_0
numpydoc 0.8.0 py37_0
odo 0.5.1 py37_0
olefile 0.46 py37_0
openpyxl 2.5.6 py37_0
openssl 1.0.2p hfa6e2cd_0
packaging 17.1 py37_0
pandas 0.23.4 py37h830ac7b_0
pandoc 1.19.2.1 hb2460c7_1
pandocfilters 1.4.2 py37_1
parso 0.3.1 py37_0
partd 0.3.8 py37_0
path.py 11.1.0 py37_0
pathlib2 2.3.2 py37_0
patsy 0.5.0 py37_0
pep8 1.7.1 py37_0
pickleshare 0.7.4 py37_0
pillow 5.2.0 py37h08bbbbd_0
pip 10.0.1 py37_0
pkginfo 1.4.2 py37_1
pluggy 0.7.1 py37h28b3542_0
ply 3.11 py37_0
prometheus_client 0.3.1 py37h28b3542_0
prompt_toolkit 1.0.15 py37_0
psutil 5.4.7 py37hfa6e2cd_0
py 1.6.0 py37_0
pyasn1 0.4.4 py37h28b3542_0
pyasn1-modules 0.2.2 py37_0
pycodestyle 2.4.0 py37_0
pycosat 0.6.3 py37hfa6e2cd_0
pycparser 2.18 py37_1
pycrypto 2.6.1 py37hfa6e2cd_9
pycurl 7.43.0.2 py37h74b6da3_0
pyflakes 2.0.0 py37_0
pygments 2.2.0 py37_0
pylint 2.1.1 py37_0
pyodbc 4.0.24 py37h6538335_0
pyopenssl 18.0.0 py37_0
pyparsing 2.2.0 py37_1
pyqt 5.9.2 py37h6538335_2
pysocks 1.6.8 py37_0
pytables 3.4.4 py37he6f6034_0
pytest 3.8.0 py37_0
pytest-arraydiff 0.2 py37h39e3cac_0
pytest-astropy 0.4.0 py37_0
pytest-doctestplus 0.1.3 py37_0
pytest-openfiles 0.3.0 py37_0
pytest-remotedata 0.3.0 py37_0
python 3.7.0 hea74fb7_0
python-dateutil 2.7.3 py37_0
pytz 2018.5 py37_0
pywavelets 1.0.0 py37h452e1ab_0
pywin32 223 py37hfa6e2cd_1
pywinpty 0.5.4 py37_0
pyyaml 3.13 py37hfa6e2cd_0
pyzmq 17.1.2 py37hfa6e2cd_0
qt 5.9.6 vc14h1e9a669_2 [vc14]
qtawesome 0.4.4 py37_0
qtconsole 4.4.1 py37_0
qtpy 1.5.0 py37_0
requests 2.19.1 py37_0
rope 0.11.0 py37_0
ruamel_yaml 0.15.46 py37hfa6e2cd_0
scikit-image 0.14.0 py37h6538335_1
scikit-learn 0.19.2 py37heebcf9a_0
scipy 1.1.0 py37h4f6bf74_1
seaborn 0.9.0 py37_0
send2trash 1.5.0 py37_0
service_identity 17.0.0 py37h28b3542_0
setuptools 40.2.0 py37_0
simplegeneric 0.8.1 py37_2
singledispatch 3.4.0.3 py37_0
sip 4.19.8 py37h6538335_0
six 1.11.0 py37_1
snappy 1.1.7 h777316e_3
snowballstemmer 1.2.1 py37_0
sortedcollections 1.0.1 py37_0
sortedcontainers 2.0.5 py37_0
sphinx 1.7.9 py37_0
sphinxcontrib 1.0 py37_1
sphinxcontrib-websupport 1.1.0 py37_1
spyder 3.3.1 py37_1
spyder-kernels 0.2.6 py37_0
sqlalchemy 1.2.11 py37hfa6e2cd_0
sqlite 3.24.0 h7602738_0
statsmodels 0.9.0 py37h452e1ab_0
sympy 1.1.1 py37_0
tblib 1.3.2 py37_0
terminado 0.8.1 py37_1
testpath 0.3.1 py37_0
tk 8.6.8 hfa6e2cd_0
toolz 0.9.0 py37_0
tornado 5.1 py37hfa6e2cd_0
tqdm 4.26.0 py37h28b3542_0
traitlets 4.3.2 py37_0
twisted 18.7.0 py37hfa6e2cd_1
unicodecsv 0.14.1 py37_0
urllib3 1.23 py37_0
vc 14.1 h0510ff6_4
vs2015_runtime 14.15.26706 h3a45250_0
wcwidth 0.1.7 py37_0
webencodings 0.5.1 py37_1
werkzeug 0.14.1 py37_0
wheel 0.31.1 py37_0
widgetsnbextension 3.4.1 py37_0
win_inet_pton 1.0.1 py37_1
win_unicode_console 0.5 py37_0
wincertstore 0.2 py37_0
winpty 0.4.3 4
wrapt 1.10.11 py37hfa6e2cd_2
xlrd 1.1.0 py37_1
xlsxwriter 1.1.0 py37_0
xlwings 0.11.8 py37_0
xlwt 1.3.0 py37_0
yaml 0.1.7 hc54c509_2
zeromq 4.2.5 he025d50_1
zict 0.1.3 py37_0
zlib 1.2.11 h8395fce_2
zope 1.0 py37_1
zope.interface 4.5.0 py37hfa6e2cd_0
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.
CAM-Gerlach
commented
5 years ago 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_runtimeconda install anaconda=5.3conda install python=3.6conda create -n spyder-test-env python=3, activate it, then install Spyder with conda install spyder.CAM-Gerlach
commented
5 years ago @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 .
mingwandroid
commented
5 years ago Good old amplitude! We need to figure out a way around this..
bigcatz
commented
5 years ago 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.
CAM-Gerlach
commented
5 years ago 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.
aperchak
commented
5 years ago 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.
janm97
commented
5 years ago 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.
CAM-Gerlach
commented
5 years ago @janm97 Did you try conda install mkl=2018.0.2?
janm97
commented
5 years ago @CAM-Gerlach Thanks a lot! That fixed it.
msarahan
commented
5 years ago 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.
mingwandroid
commented
5 years ago How did this get through testing? Can we figure that out?
ccordoba12
commented
5 years ago 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