Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Changes to create a *dll with oneAPI

AlexiaRegine
Novice
3,413 Views

Hello,

 

I'm trying to create a *dll to implement in a program of finite element methods. Everything was working fine with the Intel Parallel studio XE compiler. However, after I changed to oneAPI, my program does not recognize the *dll created. Someones know if can I fix it or come back to use the Intel Parallel studio XE.

Labels (1)
0 Kudos
12 Replies
NoorjahanSk_Intel
Moderator
3,374 Views

Hi,

Thanks for reaching out to us.

>> I changed to oneAPI, my program does not recognize the *dll created

could you please confirm whether you have created a dll file with oneAPI compiler? if you have any issues(while creating dll), please share the error log so that it will help us to get some more insights.

Please provide the following environmental details:

Parallel Studio XE version where the dll creation was successful

oneAPI version

OS & version

Compiler version.


Thanks & Regards

Noorjahan.


0 Kudos
AlexiaRegine
Novice
3,367 Views

Hi Noorjahan,

 

Yes, the dll was created with no errors, but isn't recognized by the program I'm using.

Some details:

  • Parallel Studio XE 2017 update 6 cluster edition (student license)
  • oneAPI 2021
  • Windowns 10, version 2004
  • Compiler Intel 64 for Visual Studio 2019

Regards,

Alexia

0 Kudos
NoorjahanSk_Intel
Moderator
3,301 Views

Hi,


Thanks for providing the details.


You can try copying the .dll file to your application location so that the program will be able to recognize it.


In VS you can directly copy the file to the required location by giving a command under

Configuration Properties > Build Events > Post-Build Event option

Command:

xcopy /y /d "..\..\<project>\$(IntDir)*.dll" "$(OutDir)"


You can also try adding the path to the directory containing the specific dll to  %PATH% environment variable in your system.


Hope the provided information helps, if not please provide us a sample reproducer and complete error log to get some more insights regarding your issue.


Thanks & Regards

Noorjahan.


AlexiaRegine
Novice
3,216 Views

Hi Noorjahan,

 

Sorry for the delay, but I was trying to solve another problem. In my first try to apply your suggestion, the *dll was generated normally, but wasn't regognized yet. After restart the computer and try again, the *dll was no generated because the error #10037 (see the image bellow). Now, I'm trying to fix it to try again.

 

Regards,

Alexia

WhatsApp Image 2021-09-30 at 09.47.08.jpeg

0 Kudos
mecej4
Honored Contributor III
3,116 Views

If you used a CMD window configured for Intel Fortran, and the link step failed because LINK.EXE was not found, you have a basic problem -- probably a faulty installation of Visual Studio or Intel OneAPI/Parallel Studio. Can you compile and run a simple Hello, World! program in that window? If not, that has to be fixed before you try to build a DLL and get it working with another program.

You listed several versions of Parallel Studio and OneAPI. You should use only one of them at a time, since different versions are not 100 percent compatible.

Igor_V_Intel
Employee
3,099 Views

The link command is not found in this command line shell.

I guess that you don't have required Microsoft* Visual Studio/Build Tools version installed on your machine or need to set the environment (e.g. need to run "Intel oneAPI command prompt for Intel 64 for Visual Studio 2019" to get the command line with set environment). Could you please check the sw prerequisites to use ifort from oneAPI on Windows here: https://software.intel.com/content/www/us/en/develop/articles/oneapi-fortran-compiler-system-requirements.html#inpage-nav-3-1 ?

You need to have Visual Studio 2017/2019 or Build Tools 2017/2019 installed on your machine before installing Intel Fortran compiler version 2021.

 

NoorjahanSk_Intel
Moderator
3,259 Views

Hi,

Could you please confirm whether your issue is resolved? if not, could you please provide the requested details asked in the previous post?


Thanks & Regards

Noorjahan


0 Kudos
AhmadSL
Beginner
2,072 Views

Hi, 

Currently, I am facing almost the same problem:

I generated a DLL written in Fortran, I used to use parallel studio xe and it was working properly

 

after I switched to OneAPI, after building the same DLL, the software can not find my DLLin the given directory even it is placed perfectly there with the perfect matching of the spelling, no way for any error of that type.

 

I tried a lot, and 100 % sure about it.

 

after a ton of trials, I observed that:

 

if I generate the DLL as a Release, and I generate the new DLL,  the software recognizes the DLL perfectly

If I change to Debug, ( from Visual Studio 2022, after generating the DLL,  the DLL will not be recognized.

It is somehow wired because it was working for both Release and debug in parallel studio perfectly.

 

moreover, if i changed  "process OpenMP directives" to generate sequential code to generate parallel code as shown in the screenshot, even in the release version, the generated DLL will not be recognized again!

AhmadSL_0-1668312244876.png

so all in all, the only case that it works here, is to generate a release version of the DLL by using the "generate sequential code" option.

No idea why this is happening

hopefully if somebody can help me.

Thank you

0 Kudos
Steve_Lionel
Honored Contributor III
2,043 Views

There's a lot of subtext missing in your problem report. I'm going to take a guess and say that you're running the program that uses the DLL from outside Visual Studio. Debug DLLs aren't redistributable and depend on dependent DLLs that are "in PATH" only for programs run within VS (or maybe from a VS build command window.) This explains why a release configuration works.

The OpenMP issue is that in the environment where you're running the program, the Intel Fortran OpenMP DLLs are not in PATH.

Please explain in more detail how you're running the program and whether it's on the same system where you built them.

0 Kudos
AhmadSL
Beginner
1,971 Views

Thanks Steve, for your helpful answer.

Firstly I would like to give some more details about what I am doing.

I am building some models by Fortran (coding DLLs , building it, and then launching it by a simulation software).

after you estimated my problem, I found that you are right, the issue is with the dependencies.

I downloaded a tool for checking the dependencies, and i found that I have a missing point.

kernel32.dll is depending on "ext-ms-win-oobe-query-l1-1-0.dll" while the latter is missed

so the only thing could be that ext-ms-win-oobe-query-l1-1-0.dll is missing, 

Do you think that i should look for this DLL in the web or maybe i have to add an additional directory into my project environment?

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,955 Views

From this, there is a report of issues of running on old XP installer on Windows 10.

From this, the user assumed Windows folder sysWOW64 folder was for 64-bit files and System32 folder was for 32-bit files. Whereas on x64 platform System32 holds 64-bit files and sysWOW64 holds 32-bit files.

 

Jim Dempsey

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,947 Views

That missing DLL is not the problem - it's missing on my PC too, but pretty much everything references kernel32.dll and it all works. 

0 Kudos
Reply