Problem with Fortran DLL on Another Computer

[bevo3]

Hello,

I was able to successfully build a DLL using Intel Visual Fortran. I was then able to utilize my DLL in a VB.NET project. However, when I try running the exact same VB.NET project on a different computer an exception gets thrown warning me that the DLL could not be loaded. Is there something I may be missing during the DLL build that would ensure portability from one computer to another? Both computers are operating on the same Windows OS.

Thanks!

[Steven_L_Intel1]

Your DLL references Intel (and perhaps Microsoft) run-time DLLs. If your DLL will be used by non-Fortran code only, change the project property Fortran > Libraries > Use Runtime Library to "Multithreaded (/MT)" and rebuild. Otherwise, see this article on redistributables.

[bevo3]

Hi Steve,

Thank you very much for the reply. That may very well be the problem. I am going to try it right now, and I'll let you know the outcome.

Thanks!

[bmchenry]

i'd also suggest geting dependancy walker to see what items you need (as in redistro libraries) when moving to another computer.
http://www.dependencywalker.com/
(note that you will see gpsvc.dll and ieshims.dll as 'delay-load dependancy module not found' - ignore it)
(also you could run it on the 'other' computer to see what's missing.

[Steven_L_Intel1]

Dependency walker is a fine recommendation, though the problems here are usually addressed by my reply. As for seeing what's missing, VB won't tell you.

[bevo3]

Hi Gentlemen,

Thank you both for your very helpful suggestions. Steve, the modification to the run-time library specification seems to be working now. The specification that I had previously selected was the Multithread DLL. Pardon my ignorance, but what is the difference between the Multithreaded and Multithread DLL specifications? It appears that the former is a static library spec whereas the latter a dynamic library spec. This seemed a bit counter-intuitive to me considering that I'm trying to build a DLL. I also wanted to mention that I have selected the default calling convention spec as opposed to explicitly selecting the STDCALL spec. In addition, I'm still passing only the first element of my VB array arguements ByRef just like the Intel Visual Fortran Compiler v11.1 documentation illustrates. I remember you mentioning to me in a previous thread that this was incorrect, and the more appropriate approach to passing VB.NET arrays to a Fortran DLL is illustrated in the v12 documentation (I don't have this documentation). Is there is a better way that I should be handling this? Things appear to be working for the most part, but I have noticed some suspicious results from my Fortran computations while experimenting with different input values. No exceptions are being thrown though.

Again, thank you both for helping me out with this.Trying to develop this DLL file has been quite a humbling experience for me. I am a structural engineering doctoral student who was asked to incorporate a bunch of Fortran-coded computations into a VB.NET GUI.This has definitely been a great learning experience for me, and I am very appreciative of people like you guys who are willing to provide guidance to enthusiastic, butrelatively green programmers.

Cheers!
Eric

[Steven_L_Intel1]

We assume that when you are building a Fortran DLL that you may be using it with a Fortran main program. If you choose "Multithreaded", then one copy of the run-time library gets linked into your DLL and the main program will have a second copy. Ideally, there should be only one copy of the RTL otherwise you can see strange problems.

This also means that the Fortran executable that calls a DLL needs to link to the DLL libraries, which is NOT the default, so we need to educate users on this. CVF would ask when creating the project if you wanted to do this, but Intel Fortran does not.

When you are calling the Fortran DLL from non-Fortran, then it doesn't matter as there will be only one copy of the Fortran RTL and you may as well link it into your DLL rather than provide it separately.

As for passing arrays, the correct way would be to pass the array whole and declare it similar to:

ByVal DBL_IN() As Double

[DavidWhite]

Steve,

Does this mean that:
Non-Fortran <-> Fortran DLL => use Multithreaded
Fortran <-> Fotran DLL => use Multithreaded DLL

So if I want to use the same code for both situations (probably with different entry points), I think this menas thatI need separatesolutions to build them??

Thanks,

David

[IanH]

But you can also use"Multithreaded DLL" in your case with the non-fortran program - so for that case you can choose the runtime library configuration that is most convenient to you.

Having multiple project configurations (I don't think you need to go to the extent of having separate Visual Studio solutions) might or might not be convenient for you - depends on how many projects you have and how they inter-relate. I find that project configurations are very tedious to check and diagnose, so the less complexity here the better.

(An aside to the Intel folk if they are reading - I know we're not supposed to go messing with them directly, but it would be nice if the code that writes out the xml for the .vfproj's popped lots more newlines into the file - then it would be easier to use the usual text differencing tools to diagnose when/what changes were made in properties between projects and project versions. If you need inspiration then have a look at the .vcproj format from VS2005 - one xml attribute per line.)

If you are already having to deploy the runtime DLL's for your Fortran <-> Fortran DLL case then having the separate statically linked runtime configuration seems to me like a lot of hassle for no benefit.

These days I always use the DLL form of the runtime and make sure that the relevant merge modules from Intel and Microsoft are bundled together in the msi that goes out to the users. Once they've done the install once (per ifort release) then quick-and-dirty patching can still be done by sending out new exe's or DLL's. The msi's end up a bit on the large side, but the users get over it.

[DavidWhite]

Ian,

Where do you install the Intel and Microsoft runtime libraries on the user's machine? We are moving very much into managed client, which means my apps can only be installed within the current user's area.

I have avoided the DLL libraries, preferring to have them linked within the distributed DLL, as then I know exactly where everything is, and also which version is in use without any concern about conflicting versions on the user's machine.

The Fortran <-> Fortran DLL case is relatively new, and is for a single (server) machine. I have until now been distributing the DLL with the embedded runtime libraries. However, this machine has IVF installed, but I cannot guarantee that it is always the same version as I am using. I suspect that I am in dangerous waters here with potential lilbrary conflicts as previously posted.

Your suggestions about the best deployment avenues for the multiple user situation (non-Fortran call) and the single machine (Fortran call).

Thanks,


David

[IanH]

Hmm. Your post has highlighted a problem for me. Our IT environment is becoming more restrictive too - users are currently local admin's, but not for much longer. I've been experimenting with a per-user option for my app's installation which I thought would avoid this sort of problem, but I had completely forgotten about the runtimes. Oops.

The runtime DLL's go where ever their respective merge module says they should go. I think the Microsoft ones end up in the system's side-by side assembly area, the Intel ones under %commonprogramfiles%\Intel\Shared Libraries\redist\ia32\compiler\excessively\deep\heirarchy. I don't know whether this can happen without the install being run with administrator privileges and/or I don't know whether you can use setup properties to change the locations.

I doubt it very much, which I think then means I have to go back to deploying the individual runtime DLL's to the same folder as your application's exe (as so called private assemblies in the case of the C runtime). Erk.

My per-user folder is under the localappdatafolder area (this was the default from the installation tool I use (wix)).