Problem to interface DLL with the new DPC++ intel compiler

[Youssef Menjour]

Hi Everybody,

 

Intel recently released a DPC++ (data parallel c++) compiler that optimizes speeds for Intel CPUs and GPUs.

My problem is that when I compile the functions with the normal Intel 2022 compiler (or the classic Visual Studio compiler) there is no problem and when I use the new intel DPC++ compiler LabVIEW returns an error.

Both Intel compilers work perfectly in C and C++ under visual studio. For the exemple, i made a simple function that just multiplies an int32 by 3 and returns the result as an example.

 

The DPC++ compiler is only under the X64 architecture and I use LabVIEW 2020.

 I made a video to show the problem

 

 

 

File here: https://we.tl/t-9Iwkf1IGvr you can compile by yourself and see the problem. I added all Visual studio 2022 + Intel Compiler + Intel DPC++ compiler installers in the "install" repository.

(on visual studio alt-F7 to go directly to the parameter and change the compiler - F5 to compile)

 

Is someone can tell me what's wrong ?

how I can make my DLL work with the DPC++ compiler?

 

Edited June 2, 2022 by Youssef Menjour

[dadreamer]

Did you try Release build also? I noticed, that you're exporting Mult function without explicit specification of the calling convention. By default Visual Studio exports in cdecl convention. But in LabVIEW you set stdcall convention. Likely it's not the reason for errors though.

[Youssef Menjour]

7 minutes ago, dadreamer said:

Did you try Release build also? I noticed, that you're exporting Mult function without explicit specification of the calling convention. By default Visual Studio exports in cdecl convention. But in LabVIEW you set stdcall convention. Likely it's not the reason for errors though.

 😱 😱 😱 😱 😱

Where can i specify the calling convention !!! (really sorry for the question)

 

[dadreamer]

12 minutes ago, Youssef Menjour said:

Where can i specify the calling convention !!! (really sorry for the question)

For MSVS - on the left of the function name, for LabVIEW - in the CLFN settings.

extern "C" __declspec(dllexport) int __stdcall Mult(int a)
{
  // will be exported with stdcall convention
}

 

Edited June 2, 2022 by dadreamer

[Youssef Menjour]

3 minutes ago, dadreamer said:

For MSVS - on the left of the function name, for LabVIEW - in the CLFN settings.

extern "C" __declspec(dllexport) int __stdcall Mult(int a)
{
  // will be exported with stdcall convention
}

Thank you for the information but unfortunatelly does not solve my problem

 

Regarding the release build, I haven't tried it because I didn't understand the difference and how to make it work. Could you be more explicit?
"this Shareable board exclusively owned." is very strange

[dadreamer]

10 minutes ago, Youssef Menjour said:

Regarding the release build, I haven't tried it because I didn't understand the difference and how to make it work. Could you be more explicit?

Just switch to Release option on the MSVS toolbar. As to the differences, you may read about them e.g. here . To add to there, debug builds depend on the debug version of Visual Studio Runtime libraries, whereas release builds depend on common MSVCRT DLLs, that are very likely already installed in the system. Hence if you compile debug app or library and deploy it to machines without Visual Studio installed, it will ask you for the debug DLLs or even the whole Visual Studio to be installed. Release app/DLL on the other hand usually requires Visual C++ Redistributable Runtime only.

[Youssef Menjour]

 

8 minutes ago, dadreamer said:

Just switch to Release option on the MSVS toolbar. As to the differences, you may read about them e.g. here . To add to there, debug builds depend on the debug version of Visual Studio Runtime libraries, whereas release builds depend on common MSVCRT DLLs, that are very likely already installed in the system. Hence if you compile debug app or library and deploy it to machines without Visual Studio installed, it will ask you for the debug DLLs or even the whole Visual Studio to be installed. Release app/DLL on the other hand usually requires Visual C++ Redistributable Runtime only.

Thanks a lot ! Unfortunattely it doesn't solve the problem.

This issu is very strange ! 

[dadreamer]

Maybe the reason is that LabVIEW cannot find some DPC++ Runtime library during the DLL load process (sycl.dll for instance or another one). Could you check with Dependency Walker, which libraries are in dependencies of your DLL?

[Youssef Menjour]

13 hours ago, dadreamer said:

Maybe the reason is that LabVIEW cannot find some DPC++ Runtime library during the DLL load process (sycl.dll for instance or another one). Could you check with Dependency Walker, which libraries are in dependencies of your DLL?

 

It seems that you are right (which reassures me because your reasoning is logical)

Here is the screenshot of the "dependency walker"

are there routines to integrate into my code in order to remove these objections?

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
 

 

As a reminder

 

Header.h

///////////////////////////////////////////////////////////////////////////////////////////////////////////

#pragma once

#ifdef DPCPP_DLL_EXPORTS
#define DPCPP_DLL_API __declspec(dllexport)
#else
#define DPCPP_DLL_API __declspec(dllimport)
#endif

extern "C"  __declspec(dllexport) DPCPP_DLL_API int __stdcall  Mult(int a);

///////////////////////////////////////////////////////////////////////////////////////////////////////////

dllmain.cpp

///////////////////////////////////////////////////////////////////////////////////////////////////////////

#include "pch.h"
#include "Header.h"

__declspec(dllexport) int Mult(int a)
{
     return a * 3;
}

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

///////////////////////////////////////////////////////////////////////////////////////////////////////////

 

 

dllmain.cpp Header.h

[Youssef Menjour]

 I have the same problem (LabVIEW error 13) when I use a function from the MKL library (math kernel library)

There must be a file dependency issue that is not loaded in the DLL runtime.

The question now to solve the problem is: How to add its dependencies properly.

🤔  Another question comes to mind:

Logically as it stands, my DLLs should not work if I call them with C code (this is normally independent of LabVIEW) --> I will check (need to find how to call DLL in c code)

If this is the case then our solution is to include all runtime dependencies (which is of course possible - you just have to know how to do it)

One thing is sure, I will have learned a lot!

[dadreamer]

3 hours ago, Youssef Menjour said:

are there routines to integrate into my code in order to remove these objections?

In fact your app requires the libraries on the very first level shown in Dependency Walker. The others are needed too, but they are being loaded by their "parent" DLLs, so you don't need to worry about them. Could you collapse that DLL list on the left of the DW, so we could see the first level libraries except sycl.dll and kernel32.dll? Don't look at those red warnings as they are about not finding some libraries, which likely are loaded during the runtime or have delayed loading or could even be absent in the system (as some .NET assemblies) and the app is able to run fine without them. So if only sycl is necessary, then you could either provide the path to it in your PATH environment variable or try to put it near your own DLL and check, whether LabVIEW loads it all without errors.

[Neil Pate]

Maybe completely unrelated, but I had a similar issue some time ago. I had some software which just did not run on a certain PC, it gave some weird error message. The error was actually in the LabVIEW "Mean.vi" which is part of the advanced analysis libraries.

See this thread for my post.

To cut a long story short, I had to add a setting to my PC environment variables. Doing so allowed the Math Kernel libraries to work with my CPU. Something similar to this. 

MKL_DEBUG_CPU_TYPE=4

Edited June 3, 2022 by Neil Pate

[Youssef Menjour]

21 hours ago, dadreamer said:

In fact your app requires the libraries on the very first level shown in Dependency Walker. The others are needed too, but they are being loaded by their "parent" DLLs, so you don't need to worry about them. Could you collapse that DLL list on the left of the DW, so we could see the first level libraries except sycl.dll and kernel32.dll? Don't look at those red warnings as they are about not finding some libraries, which likely are loaded during the runtime or have delayed loading or could even be absent in the system (as some .NET assemblies) and the app is able to run fine without them. So if only sycl is necessary, then you could either provide the path to it in your PATH environment variable or try to put it near your own DLL and check, whether LabVIEW loads it all without errors.

It works !!!  💪 SOLVED

 

 

I put sycl.dll at the same place of my called DLL and no error LabVIEW well worked !!!

Dadreamer many thanks !!!!!!! 💪 SOLVED

18 hours ago, Neil Pate said:

Maybe completely unrelated, but I had a similar issue some time ago. I had some software which just did not run on a certain PC, it gave some weird error message. The error was actually in the LabVIEW "Mean.vi" which is part of the advanced analysis libraries.

See this thread for my post.

To cut a long story short, I had to add a setting to my PC environment variables. Doing so allowed the Math Kernel libraries to work with my CPU. Something similar to this. 

MKL_DEBUG_CPU_TYPE=4

Ok let's now try to solve this one now !! 

 

[Youssef Menjour]

On 6/3/2022 at 4:24 PM, Neil Pate said:

Maybe completely unrelated, but I had a similar issue some time ago. I had some software which just did not run on a certain PC, it gave some weird error message. The error was actually in the LabVIEW "Mean.vi" which is part of the advanced analysis libraries.

See this thread for my post.

To cut a long story short, I had to add a setting to my PC environment variables. Doing so allowed the Math Kernel libraries to work with my CPU. Something similar to this. 

MKL_DEBUG_CPU_TYPE=4

Thank you for your help but I'm not sure thats the good way to solve this problem because if i well understood, you propose to make modification on my configuration machine to make the VI well working.

It's not user friendly if i want to use MKL inside an exported library.(Or have to script it to automatize the installation)

By the way i looked also about the dependancy 

I found MKL_intel_THREAD.2.DLL (C:\Program Files (x86)\Intel\oneAPI\mkl\2022.1.0\redist\intel64)unfortunaelly moving this DLL doesn't worked. (Well tried !)

 

 

--> i suppose MKL_intel_THREAD.2.DLL is calling other DLL so i have to scan this one to know dependany etc etc ... --> maybe a better way to solve this one (edit : done uper image 🤠 --> tried and failed)

 

 

Is it possible to script  PATH environment variable modification to make it more acceptable ? (I already have the answers - It's yes, but my actual knowledge on this subject are low)

We can inspire from  DNNL library (another library inside the intel package) -  Intel propose a script to fix environnent variable but when i launch it on my cmd console seems does not work.

I suppose i make it bad.

 

vars.bat

Edited June 6, 2022 by Youssef Menjour

[dadreamer]

My assumption is that if you already have MKL Runtime installed (I see that it is so), then your PATH environment variable should contain full path to the \bin\ directory of the MKL parent directory (as stated in mklvars_intel64.bat or mklvars.bat). But I have never compiled DLLs with MKL linking, so you better to ask on some C/C++ forums or stackoverflow or experiment with it on your own.