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.
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
OS & version
Thanks & Regards
Yes, the dll was created with no errors, but isn't recognized by the program I'm using.
- Parallel Studio XE 2017 update 6 cluster edition (student license)
- oneAPI 2021
- Windowns 10, version 2004
- Compiler Intel 64 for Visual Studio 2019
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
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
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.
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.
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.
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
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!
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.
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.
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?
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.