Wrong dll version of mkl_intel_thread.dll called at run time

[h88433]

Hi,

I am using version 10.2.5.035 of the MKL. I am building a 64 bit DLL and linking against the MKL using the link line advisor which is compiled through the intel C++ compiler integrated in visual studio 2008. I am running windows 7 64 bit.
The Dll is called from python using the ctypes interface (64 bit python version 2.7). Im am recieving tht error from ctypes, "Invalid win32 application". A load test on the DLL using "Inspect Eye" shows that the mkl_intel_thread.dll results in the same error message. This little program can be downloaed from silurian software.
To solve the problem I went into the MKL directory and changed the subdirectory 'ia32' to ia32_bak. Then I copied the directory emt64 and renamed in to ia32. After this the DLLL worked both from ctypes and Inspect Eye.
How can I solve this problem so that the correct version of mkl_intel_thread.dll is called fro win64.

Thanks for any help you may be able to offer.
John McElhaney

[Chao_Y_Intel]

John,

Could youcheck on the PATH environment,and findif the IA32 is included in the PATH environment, If so, it needs to use the 64 bit library path:

Thanks,
Chao

[h88433]

Hi Chao,

Thanks for your reply,

I have checked the Path again and I see that I have defined both libraries,

C:\Program Files (x86)\Intel\MKL\10.2.5.035\ia32\bin;
C:\Program Files (x86)\Intel\MKL\10.2.5.035\emt64\bin;

Are you saying that only the 64 bit path i.e., emt64\bin' should be defined ? If so, does that mean that 32 bit DLLs on my system run with the 64 bit mkl_intel_thread.dll ??

Cheers,
John

[h88433]

Hi Chao,
I tried loading a 32 bit dll using the 64 bit mkl_intel_thread.dll and it failed. It seems I have to rebame directories or change path at run time in order to force the uses of the correct 32 or 64 bit mkl_intel_thread.dll.
Do you know of a more elegant solution ? This looks like a design bug with the way the MKL is called up !
Cheers John

[TimP]

If you are running a 64-bit application, it should pass over the 32-bit dlls which are on your path, but it does take some time at initial load and may run into a Windows limit on length of PATH entry.

[h88433]

Hello Tim and thanks for your reply.
I have been very careful to keep the path as short as possible by e.g. by subtituting Progra~2 for 'Program Files (x86)', and removing paths I dont need. The path to ia32, and emt64 are close to the start of the path string anyway so I dont think that is an issue.
Thus, the problem remains. I have the same issue on two different computers, one running win7 x64, and the other win8 cp x64.
Every time I rename the directories the correct mkl_intel_thread.dll is called up. I have two versions of this dll. One is 32 biit, and the other 64 bit. I have observed this behavior in both DLLs using inspectEye, and python cytpes. When there is an error, the message 'Is not a valid win32 application" occurs. This is seen using inspectEye, and ctypes.
Thanks in advance,
John

[SergeyKostrov]

Hi John,

Quoting h88433

I tried loading a 32 bit dll using the 64 bit mkl_intel_thread.dll and it failed.

[SergeyK] This is absolutely expected result because you can't use 32-bit and 64-bit modules or DLLsin one
address space without application of special techniques, like 'thunks'.

It seems I have to rebame directories or change path at run time in order to force the uses of the correct 32 or 64 bit mkl_intel_thread.dll.
Do you know of a more elegant solution ? This looks like a design bug with the way the MKL is called up !

A right solution forthe DLLs namingshould look like:

32-bit platform - 'DllName32.dll'
64-bit platform - 'DllName64.dll'

Unfortunately, inmanysoftware productsthat simple rule is not used.

Best regards,
Sergey

[Chao_Y_Intel]

John,

A few thoughts that may resolve the problem:

1> Link with the static libraries, and it will depends on the DLLs.

2> Build the customer DLLs. With this way, you can rename the DLLs

3> Just put the MKL DLLs at the same directory with your applications, and remove the IA32 bit/ 64 bit directory from the system PATH.

Thanks,
Chao

[h88433]

Hi All,
Thanks for your inputs. I must admit that I am not satisfied with this matter. It should be possible by design to run either 32 or 64 bit dlls. For a customer application, it is clear that we can simply build and install 32 or 64 bit versions individually. For a developer, it is very irritating having to rename paths or directories depending on whether I am working with 32/64 bit versions.
Does MKL 10.3 solve this problem ?
Cheers,
John

[mecej4]

> I must admit that I am not satisfied with this matter.

Can you name a system where you find this matter resolved in a satisfactory way?

There is a conflict between your two implied requirements:

(1) having two files with the same name in a directory, and

(2) development scripts and commands that are the same for 32-bit and 64-bit targets.

Many operating systems expect to work with files without having to examine the file contents, to the extent possible. A filename convention, strictly followed, makes this possible. However, to do so with executable files, different suffixes would be needed, such as *.exe32 and *.exe64. In turn, all scripts would have to have 32-bit and 64-bit versions.

Microsoft decided when developing Windows that instead of .exe16, .exe32 and .exe64 it would use .exe. Therefore, executable files contain "magic" bytes to (i) signify that the file is executable and (ii) what the target processor and OS should be. In these circumstances, you cannot have two files with the same name (case differences ignored) within the same directory.

Similarly the librarian LIB.EXE will refuse to build a mixed library:

fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

On the other hand, many tools such as MAKE are "bitness unaware", so makefiles often contain IF..THEN..ELSE blocks of actions with a test on the OS, word-size, etc.

[h88433]

Hi, I regularly build 32 and 64 bit static libraries to link against in 32/64 bit applications. I allways name these,

library_win32.lib, library_win64.lib

why cant that be possible ?

cheers, john

[mecej4]

If you are willing to use different names, there should be no problems.

If you are using a makefile, you use conditional segments to build for 32-bit or 64-bit targets.

If using VS, you would have to specify the respective library names for each configuration under "additional libraries".