topic Problem with a dll in Intel® Fortran Compiler

Problem with a dll

Brian_Allison — Tue, 12 Oct 2010 14:46:24 GMT

I don't know if this is the right place or not for this, but here goes.

We have a program that uses a dll created with IFC. It works fine on our computers, XP and Win 7.

We have some clients over seas that are encountering a problem with the dll. THey are getting an error message.

"DLL Loading Error: relap5l.dll"
Thats it! The next thing they are asked to do is click OK.
Any ideas?

Problem with a dll

Steven_L_Intel1 — Tue, 12 Oct 2010 15:28:21 GMT

That error message would appear to be coming from the application. I would guess that the application tries to dynamically load this DLL using LoadLibrary and it fails. It is not coming from Intel Fortran itself.

Problem with a dll

Brian_Allison — Tue, 12 Oct 2010 15:32:10 GMT

but why would it be only on certain machines?

Problem with a dll

Steven_L_Intel1 — Tue, 12 Oct 2010 15:42:03 GMT

The DLL being loaded may have dependencies on other DLLs that are not present on some systems. Use Dependency Walker to check.

Problem with a dll

Brian_Allison — Tue, 12 Oct 2010 15:47:58 GMT

It looks like in dependency walker that the dll is relying on two lib files from INTEL.

LIBIFCOREMD.DLL and LIBMMD.DLL

So I figured out that machines that do not have the IFC installed on them they get the DLL error. I copied the two LIB DLL files into the same folder as the main program on a machine that was gettign the error, and now the error is gone.

Why is my dll relying on the IFC dll's.

Problem with a dll

Steven_L_Intel1 — Tue, 12 Oct 2010 18:02:35 GMT

Because, by default, when you build a DLL it links to DLL libraries. You can change that if the DLL will not be called from Fortran. Or you can provide our redistributable installer.

Problem with a dll

Arjen_Markus — Wed, 13 Oct 2010 07:49:38 GMT

How do you force this? We encounter the very same problem: the DLL is called by a Java program in our case.

Regards,

Arjen

Problem with a dll

anthonyrichards — Wed, 13 Oct 2010 09:00:39 GMT

I think it means that, when you specify to build a DLL, you can choose the option to satisfy all external dependencies by linking to the static library versions rather than the DLL versions. That way all external dependency code should become part of your DLL (which will of course be bigger as a consequence) and the DLL will not then need to link in other DLL's in order to load the code for the external dependencies.

This presupposes that there exist static versions of all of the DLLs on which your Fortran code depends.

Problem with a dll

Arjen_Markus — Wed, 13 Oct 2010 09:12:09 GMT

Yes, but I am especially interested in suppressing the dependencies to the DLL versions of the Intel runtime
libraries. If the program depends on the DLL versions, we need to redistribute them, complicating the distribution mechanism (some of our clients have a very restricted environment!)

I think there is a compile/link option for that, but I have not found it yet in the online documentation.

Regards,

Arjen

Problem with a dll

IanH — Wed, 13 Oct 2010 11:14:23 GMT

Consider reading the help for the /libs:static option.

Problem with a dll

Arjen_Markus — Wed, 13 Oct 2010 12:33:36 GMT

Thanks, I have read it - the phrase "search for unresolved references" did not strike me as
belonging to the option I needed. Reading the lemma for the option /libs:static does me confidence
that that is what I should use.

Regards,

Arjen

Problem with a dll

Steven_L_Intel1 — Wed, 13 Oct 2010 15:40:44 GMT

If you are building in Visual Studio, you want Fortran > Libraries > Use Runtime Libraries > Multithreaded.

Problem with a dll

DavidWhite — Thu, 14 Oct 2010 01:50:32 GMT

I use the Multithreaded option (/libs:static /threads) and I do not need to provide any runtime libraries to my users - just the DLL.

David