Numpy: Numpy 1.10.2 + MKL = falha (Windows)

Criado em 2 jan. 2016  ·  30Comentários  ·  Fonte: numpy/numpy

Seja usando o Anacondas Numpy ou aquele empacotado aqui, o Numpy trava com algumas funções. As mensagens de erro são
Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll.

e

The procedure entry point mkl_aa_fw_get_max_memory could not be located in the dynamic link library C:\Program Files\Python 3.5\lib\site-packages\numpy\core\mkl_intel_thread.dll. .

Numpy 1.9.2 (testado em Python 3.3.5) funciona bem (mas também não tem .dll acima em seu diretório).

Por enquanto, fiz o downgrade para Numpy 1.9. Eu sei que você não testa contra MKL, mas talvez você tenha algumas dicas?

Informação do sistema

>>> platform.platform()
'Windows-10.0.10586'

>>> sys.version
'3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)]'

>>> np.__version__
'1.10.2'

>>> np.show_config()
blas_opt_info:
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
lapack_mkl_info:
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
lapack_opt_info:
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
blas_mkl_info:
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
mkl_info:
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
openblas_lapack_info:
  NOT AVAILABLE
00 - Bug build

Comentários muito úteis

@cgohlke Estas são as DLLs encontradas no meu diretório do Windows:

['System32\\libiomp5md.dll',
 'System32\\mkl_core.dll',
 'System32\\mkl_def.dll',
 'System32\\mkl_intel_thread.dll',
 'SysWOW64\\libiomp5md.dll',
 'SysWOW64\\mkl_core.dll',
 'SysWOW64\\mkl_intel_thread.dll',
 'SysWOW64\\mkl_p4.dll',
 'SysWOW64\\mkl_p4m.dll',
 'SysWOW64\\mkl_p4m3.dll',
 'SysWOW64\\mkl_p4p.dll']

Tentar redefinir meu PATH com SET PATH=; antes de invocar o python ainda trava, mas remover as DLLs acima inteiramente do diretório do Windows interrompe o travamento. Parece um problema de precedência de caminho @carlkl.

Todos 30 comentários

Hmm, não sei o que está acontecendo aqui. A Intel fez algumas alterações na construção, mas não acho que estejam envolvidas. Python 3.5 é um possível culpado, pois é compilado com um VS mais recente no Windows. pensamentos @cgohlke ?

Acho que sua melhor aposta é fornecer um reprodutor (quais são as "algumas funções" que produzem isso?) E esperar que @cgohlke apareça com a resposta ou então arquive um bug com o Anaconda (já que eles têm os recursos para oferecer suporte suas compilações MKL e nós não).

Desculpe pelas "algumas funções" :) - travou indiretamente através do matplotlib.

Isso trava da mesma forma:

A = np.arange(2*3).reshape(2,3).astype(np.float32)
B = np.arange(2*3*2731).reshape(2,3,2731).astype(np.int16)

np.dot(A, B)

Fiz uma verificação rápida com o mais recente @cgohlke numpy (1.10.2) python-3.4 (64 bits), bem como python-3.5 (64 bits) no meu laptop:

>>> np.show_config()
openblas_lapack_info:
  NOT AVAILABLE
lapack_mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
lapack_opt_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
blas_mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
blas_opt_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
>>> import numpy as np
>>> A = np.arange(2*3).reshape(2,3).astype(np.float32)
>>> B = np.arange(2*3*2731).reshape(2,3,2731).astype(np.int16)
>>> np.dot(A, B)
array([[[  13655.,   13658.,   13661., ...,   21839.,   21842.,   21845.],
        [  38234.,   38237.,   38240., ...,   46418.,   46421.,   46424.]],

       [[  38234.,   38246.,   38258., ...,   70970.,   70982.,   70994.],
        [ 136550.,  136562.,  136574., ...,  169286.,  169298.,  169310.]]], dtype=float32)

Ambos funcionam conforme o esperado para mim.

Eu acho que o erro Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll pode ser explicado devido a uma versão incorreta de mkl_intel_thread.dll encontrada em algum lugar em PATH . Localizar DLLs de MKL estendendo PATH como feito em numpy + MKL é frágil se outro tempo de execução de MKL estiver instalado no sistema.

Há algum arquivo libiomp5md.dll ou mkl_*.dll nos diretórios C: \ Windows *?

@cgohlke , em numpy + MKL você introduziu _init_numpy_mkl() para adicionar numpy.core a PATH .

Você considerou a seguinte abordagem de https://gist.github.com/matham/f6a07f8fb5e403feb440 para alterar a ordem de pesquisa do DLL?

Veja também:
https://pytools.codeplex.com/workitem/1627 (de onde vem)
https://github.com/numpy/numpy/wiki/windows-dll-notes#python -dlls
http://stackoverflow.com/questions/23804438/find-library-in-ctypes

@cgohlke Estas são as DLLs encontradas no meu diretório do Windows:

['System32\\libiomp5md.dll',
 'System32\\mkl_core.dll',
 'System32\\mkl_def.dll',
 'System32\\mkl_intel_thread.dll',
 'SysWOW64\\libiomp5md.dll',
 'SysWOW64\\mkl_core.dll',
 'SysWOW64\\mkl_intel_thread.dll',
 'SysWOW64\\mkl_p4.dll',
 'SysWOW64\\mkl_p4m.dll',
 'SysWOW64\\mkl_p4m3.dll',
 'SysWOW64\\mkl_p4p.dll']

Tentar redefinir meu PATH com SET PATH=; antes de invocar o python ainda trava, mas remover as DLLs acima inteiramente do diretório do Windows interrompe o travamento. Parece um problema de precedência de caminho @carlkl.

@cgohlke , proponho a seguinte mudança para testar com numpy + MKL's __init__.py

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    import ctypes
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # extend DLL search order with numpy.core
    # See https://github.com/numpy/numpy/wiki/windows-dll-notes#python-dlls
    # and https://pytools.codeplex.com/workitem/1627
    try:
        _AddDllDirectory = ctypes.windll.kernel32.AddDllDirectory
        _AddDllDirectory.argtypes = [ctypes.c_wchar_p]
        # Needed to initialize AddDllDirectory modifications
        ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000)
    except AttributeError:
        _AddDllDirectory = ctypes.windll.kernel32.SetDllDirectoryW
        _AddDllDirectory.argtypes = [ctypes.c_wchar_p]
    try:
        _core = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        _AddDllDirectory(_core)
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

remover DLLs acima inteiramente do diretório do Windows interrompe o travamento.

Boa viagem.

Proponho a seguinte mudança para testar com numpy + MKL __init__.py

Isso realmente não funcionará em sistemas mais antigos e, mais importante, interrompe pacotes que dependem da ordem de pesquisa de DLLs do sistema. Pode ser aceitável para distribuições como Anaconda ou WinPython.

Acho engraçado que inicialmente encontrei o método AddDllDirectory no wiki numpy, que foi creditado parcialmente a @carlkl , mas então meu uso dele foi proposto aqui por @carlkl como um exemplo, e acabei aqui porque de um problema com esse código de exemplo ao pesquisar numpy por AddDllDirectory . É um círculo completo ...

De qualquer forma, gostaria de observar para outras pessoas que consideram usar isso, que a linha ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) (e qualquer outro sinalizador nenhum-zero) causa ImportError: DLL load failed: The parameter is incorrect exceções ao carregar alguns dlls. Para mim, isso só aconteceu especificamente com uma extensão construída mingw-w64 (mingwpy) que vinculava a dlls ffmpeg que foram compilados em debian com mingw-w64. Mas não sei se isso foi o responsável.

No entanto, porque python chama LoadLibraryEx apenas com LOAD_WITH_ALTERED_SEARCH_PATH e não com LOAD_LIBRARY_SEARCH_USER_DIRS , a menos que SetDefaultDllDirectories também seja chamado com LOAD_LIBRARY_SEARCH_USER_DIRS , LoadLibraryEx não pesquisará os diretórios adicionados com AddDllDirectory . Para mim, isso parece um pouco frágil de usar, então acho que voltarei a adicionar o diretório dll ao caminho com os.environ . Eu me pergunto se devo atualizar o wiki com essas informações?

De qualquer forma, espero que isso não esteja muito fora do assunto.

@matham , este trecho de código deve ser creditado a _zooba_ - consulte https://pytools.codeplex.com/workitem/1627. A linha ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) não muda o comportamento de LoadLibraryEx com LOAD_WITH_ALTERED_SEARCH_PATH . Ele _esperadamente_ altera o comportamento de LoadLibraryA (_without_ LOAD_WITH_ALTERED_SEARCH_PATH ) que costumava carregar MKL_INTEL_THREAD.DLL logo após random \ mtrand.pyd ser carregado e MKL_RT.DLL então chama MKL_INTEL_THREAD.DLL :

log do depency walker durante python -c "import numpy"

...
LoadLibraryExW("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\mtrand.cp35-win_amd64.pyd", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from "d:\devel\py\python-3.5.0.amd64\PYTHON35.DLL" at address 0x00000000587E7747.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" at address 0x000007FEF3310000.  Successfully hooked module.
DllMain(0x000007FEF3310000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" called.
DllMain(0x000007FEF3310000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" returned 1 (0x1).
LoadLibraryExW("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\mtrand.cp35-win_amd64.pyd", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned 0x000007FEF3310000.
LoadLibraryA("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\mkl_intel_thread.dll") called from "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_RT.DLL" at address 0x000007FEE17C4772.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_INTEL_THREAD.DLL" at address 0x000007FEE0520000.  Successfully hooked module.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_CORE.DLL" at address 0x000007FEDEEC0000.  Successfully hooked module.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\LIBIOMP5MD.DLL" at address 0x000007FEE43E0000.  Successfully hooked module.
...

@carlkl true, mas eu estava me referindo ao wiki: (thanks to Steve Dower for the fragment, Carl Kleffner for finding it) , que presumi que fosse você :)

A fragilidade a que me referia é que, em geral, pode haver algum outro código executado entre a chamada SetDefaultDllDirectories que define esse sinalizador e quando a biblioteca é realmente carregada. Por exemplo, se você importar algo que chama SetDefaultDllDirectories talvez com um valor (por exemplo, 0) que pode resultar na dll não encontrada posteriormente quando importado. Embora eu ache que isso pode não ser um problema aqui se for importado imediatamente.

@cgohlke , há algo errado em pré-carregar MKL_RT.DLL , MKL_INTEL_THREAD.DLL e MKL_CORE.DLL com nome de caminho explícito para numpy.core dentro de _init_numpy_mkl() ? Não tenho certeza, porém, se o carregamento gradual de outras DLLs MKL necessárias funciona então.

@cgohlke ,

o snippet a seguir garante (?) que as DLLs MKL sejam carregadas de numpy.core e não de qualquer sistema Windows ou pasta redist da Intel. A ordem de carregamento das DLLs é importante. Pelo menos funciona no Windows 7 python-3.4 bit.

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    import ctypes
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # preload MKL DLLs from numpy.core
    try:
        _core = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        for _dll in ('mkl_rt', 'libiomp5md', 'mkl_core', 'mkl_intel_thread', 
                     'libmmd', 'libifcoremd', 'libimalloc'):
            ctypes.cdll.LoadLibrary(os.path.join(_core,_dll))
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

Eu tive o mesmo problema e rastreiei de volta para instalar mkl_intel_thread.dll em C:\Windows\System32 conforme indicado por danielgeier.
A versão mais antiga não tinha mkl_aa_fw_get_max_memory entre outras coisas.
O tempo de criação coincidiu com a instalação dos drivers de áudio Asio4all. Depois de desinstalá-los, que removeu várias dlls, funcionou novamente (melhor do que apenas deletar dlls no system32 sozinho).
Brinquei de reverter e atualizar a distribuição do anaconda, mas não funcionou. Eu também não consegui desabilitar o mkl com o anaconda no windows.

@ sebastian-schmidt, você pode tentar, se o carregamento explícito de DLLs MKL da pasta numpy / core funcionar para você, mesmo com DLLs MKL desatualizadas instaladas na pasta de sistema do Windows. Veja acima: https://github.com/numpy/numpy/issues/6923#issuecomment -169073613

@carlkl , onde devo adicionar o snippet?
Tentei adicioná-lo ao arquivo que usei como teste: https://gist.github.com/sebastian-schmidt/9bb97354b481750209fd3dac1e748d31 e não funcionou.
O caminho associado é apenas um subdiretório de onde chamo o arquivo.
Devo adicioná-lo ao módulo init do Numpy?

A função _init_numpy_mkl() faz parte das rodas @cgohlke numpy + mkl. Você pode encontrá-lo no arquivo __init__.py . Não faz parte das fontes oficiais de entorpecimento

Aqui está a versão encontrada em numpy-1.10.4+mkl-cp34-none-win32.whl

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # prepend the path of the Intel runtime DLLs to os.environ['PATH']
    try:
        path = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        if path not in os.environ.get('PATH', ''):
            os.environ['PATH'] = os.pathsep.join((path, os.environ.get('PATH', '')))
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

Essa função adiciona o numpy/core pasta para o PATH ambiente. No entanto, as DLLs encontradas na pasta do sistema Windows são preferidas às DLLs encontradas no PATH. Bem-vindo ao inferno do DLL.

A versão alternativa desta função https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 carrega as DLLs MKL de numpy/core na ordem correta _sem_ alterando o ambiente PATH . Todos os nomes de DLLs são fornecidos como nomes de arquivo explícitos com nome de caminho totalmente qualificado, portanto, não espero problemas com o sombreamento de DLLs na pasta do sistema Windows, mas não testei isso.

No entanto, eu não me importei em congelar numpy neste trecho de código.

Mudei _init_numpy_mkl() na distribuição do Anaconda para a sua versão e funcionou (com dlls incompatíveis em windows/system32 .

Que bom ouvir!

O código em _init_numpy_mkl () é parte da distribuição numpy de @cgohlke e está sob sua responsabilidade.
@cgohlke : algum comentário sobre https://github.com/numpy/numpy/issues/6923#issuecomment -169073613?

@ sebastian-schmidt, você pode testar a versão usando AddDllDirectory (ou SetDllDirectoryW como reserva): veja acima: https://github.com/numpy/numpy/issues/6923#issuecomment -168490201

@carlkl , a versão AddDllDirectory / SetDllDirectoryW também funciona.
O teste sempre foi apenas o exemplo np.dot() de danielgeier.
Em uma nota lateral, o software que instala as bibliotecas mkl era Amplitube e não os drivers Asio4all.

Eu também rastreei o problema até o Amplitube.

quando tentei: import matplotlib.pyplot as plt com ambas as versões do init, recebi um erro:

---> 60 import matplotlib._png as _png
     61 ####################
     62 

ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.

Então mudei de volta para a versão original do Anaconda e deixei o Amplitube desinstalado.

@ sebastian-schmidt, pelo menos funciona para mim. Importar numpy, scipy, matplotlib._png funciona sem problemas na minha caixa.

No entanto, desinstalar as DLLs MKL das pastas do sistema Windows parece a melhor solução para esse tipo de problema.

Hora de encerrar este problema?

Oi pessoal. Caso alguém ainda esteja com esse problema. Eu tenho 1.12 + mkl numpy e tive o mesmo problema. Desinstalei o Amplitube 3 e agora está tudo funcionando!

Oi pessoal,

Acabei de instalar o pacote numpy + mkl 1.13 mais recente daqui por @cgohlke .

Estou executando o Anaconda c / Python 3.6.1 64 bits no Windows 7.

Depois disso, também estou recebendo esse problema de DLL, ele estava funcionando bem para a v1.12 do mesmo site anterior.

Para adicionar, na verdade todo o código funciona em um bloco de notas Jupyter ... Isso só acontece em um console.

@carlkl Eu procurei na minha pasta Anaconda por _init_numpy_mkl mas não consegui encontrar o arquivo que continha esta string. Anexar manualmente numpy/core à minha variável PATH env também não funcionou.

Alguma outra sugestão?

Obrigado.

quando importei o skimage, encontrei o problema "não é possível carregar o mkl_intel_thread.dll".
Não consigo encontrar nenhum mkl_intel_thread.dll no windows / system32, então apaguei o libiomp5md.dll dessa pasta como @cgohlke mencionou, funciona! muito obrigado! o problema me incomodou semanas. De qualquer forma, espero que outras pessoas com esse problema possam obter ajuda com isso. Tente encontrar libiomp5md.dll, pode ajudar.

Eu me pergunto se https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 funciona nesse caso sem a necessidade de remover DLLs MKL do windows / system32. Este trecho mostra que é possível carregar sete (mas não todas) DLLs MKL na pasta numpy / core sem a necessidade de passar libs extras para a variável de ambiente PATH ou usar outros truques. É importante carregar essas 7 DLLs na seqüência correta. Todas as outras DLLs MKL necessárias são carregadas automaticamente de numpy / core em vez da pasta windows / system32.

Ainda não está claro se isso funciona em todos os cenários concebíveis. Por exemplo, aplicativos python congelados. Além disso, as versões do sistema operacional Windows podem diferir no comportamento de carregamento da DLL.

Parece-me vantajoso investigar melhor essa variante.

Fomos e voltamos com SetDefaultDllDirectories , # 10229 adicionado e # 11493 removido. Acho que fomos o mais longe que podemos com isso. Parece que a melhor opção é remover outras cópias do mkl do PATH.

Por favor, reabra se você discordar.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

Foadsf picture Foadsf  ·  3Comentários

astrofrog picture astrofrog  ·  4Comentários

dmvianna picture dmvianna  ·  4Comentários

dcsaba89 picture dcsaba89  ·  3Comentários

keithbriggs picture keithbriggs  ·  3Comentários