Moving FORTRAN dlls to other computers for Excel macros

[fthomassy]

Hi all,

First let me say I am not a professional programmer but have been using FORTRAN off and onfor ~20-years as an engineer. I have created a series of calculation subroutines which I expose in various applications as dlls. I recently moved from CVF-6.6 to IVF-9.1 because compiler support in some applications is dropping CVF. I setup my projects in Visual Studio and have successfully re-created all my applications on my compile machine.

My problem comes in moving dlls created for Excel from my compile computer to another application computer. With CVF there were a few dlls I had tomove to the system32 directory and all was good but that solution does not seem to work for IVF. I have used Dependency Walker to track dll references and see that MSJAVA.dll is not found and MPR.dll has an unresolved issue. But this is true for BOTH the compile and application computer. In general, the IVF dllsshow a laundry list of dependencies where CVF dllsonly have a few.

I assume that I need education on creating an distribution package but after looking though forum posts I just don't know what to do next.

Your advice is appreciated . . . Fern

[DavidWhite]

Fern,

Other files you should make sure are available on the path of the 2nd computer are:

MSVCR80.dll

Microsoft.VC80.CRT.manifest

Also, if you are using VBA macros as add-ins, it is best to put them into C:Documents and SettingslogonidApplication DataMicrosoftExcelXLSTART rather than the Add-Ins folder, as Excel workbooks hardcode the path to the addin in function calls, amking migration of these files across computers impossible. For some reason, when placed in the XLStart folder. This doesn't happen.

Build your App with /libs:static, otherwise you also have to distribute the IVF runtime libraries.

As for creating distribution packages, I use NIS Edit to create the scripts.

Regards,

David

[fthomassy]

David,

Thank you, I needed to compile with /libs:static. Everything works fine and I no longer need to add any dlls to the second computer. You were correct that MSVCR80.dll was one that Dependency Walker flagged with my non-transportable dlls but I don't need it after making the/libs:staticcorrection.

I must say that /libs:static was counter intuitive. I stared at that option a couple of time in my hunt for the right button to push but my mind said "well your making a dll so static isn't the answer so move on". So much for intuitive logic. I can now see the difference in /dll and /libs.

I will look into NIS Edit and distributing my macros as an add-in. I had not considered an add-in ... that would make life much easier at update time.

Again, thanks for your time and consideration.

Cheers . . . Fern

[schwarem]

I am having a similar problem. I have an executable that depends on 4 DLLs. When I move it to a different computer, I get an error. I used dependency walker to check what it is looking for. It is looking for LIBIFCOREMD.dll, LIBMMD.dll, MSVCR90.dll, and DWMAPI.dll. I tried putting the /libs:static in the compilation options for both the DLLs and the executable, but I still can't move it to another computer. My command line arguments look like this:

/nologo /module:"Release" /object:"Release" /c /libs:static /MT

Any help would be greatly appreciated.

[Steven_L_Intel1]

What is the error? Exact text, please.

[Peter_A_1]

Quoting - schwarem

I am having a similar problem. I have an executable that depends on 4 DLLs. When I move it to a different computer, I get an error. I used dependency walker to check what it is looking for. It is looking for LIBIFCOREMD.dll, LIBMMD.dll, MSVCR90.dll, and DWMAPI.dll. I tried putting the /libs:static in the compilation options for both the DLLs and the executable, but I still can't move it to another computer. My command line arguments look like this:

/nologo /module:"Release" /object:"Release" /c /libs:static /MT

Any help would be greatly appreciated.

[Peter_A_1]

Sorry about any double enties:

How did the thread end?

I am shipping a DLL for another applictaion(it seems I need only LIBIFCOREMD.dll, LIBMMD.dll, MSVCR90.dll)

1. is there a technical note orutility to automate and guarrantee you have the right bundle (I use Dependency Walker..)

2. Can the static linking eliminate all the extras and, if so, how? Just adding
/nologo /module:"Release" /object:"Release" /c /libs:static /MT

to the Link in VS (2008)?

Thanks

[Steven_L_Intel1]

Dependency Walker is fine. If you know that your DLL will never be called by Fortran code, feel free to link it statically. In Visual Studio, set the property Fortran > Libraries > Runtime Library to "Multithreaded". You don't need to add anything manually to the options. From the command line, use /libs:static /thread

[Peter_A_1]

Quoting - Steve Lionel (Intel)

Dependency Walker is fine. If you know that your DLL will never be called by Fortran code, feel free to link it statically. In Visual Studio, set the property Fortran > Libraries > Runtime Library to "Multithreaded". You don't need to add anything manually to the options. From the command line, use /libs:static /thread

Hi Steve

Thanks for the quick reply, andsorry, Idid not give the full story. I am supplying a C++DLL ("CPPDLL") that callsroutines from my IVF DLL ("IVFDLL"). SoI have just 'shipped'the twoDLLS plus the three extra I needed from Intel Fortran.

Can I either
1. at least make my DLL somehow self contained/ static? (ship only CPPDLL and IVFDLL)
2. Or even make the C++ DLL self contained/ static? (Ship only CPDLL)

and if so how.? I suspect that the "static" concept will only appply to a final exe (that does not apply here).

Thanks

[Steven_L_Intel1]

The "static" concept does apply to DLLs - you can make a DLL that has no external dependencies on other DLLs. By default, a DLL project specifies that it links to DLL run-time libraries. You can change that to the static libraries ("Multithreaded" or /MT [/libs:static /threads])

The problem you may run into is if there's a need to share things such as allocated memory between the DLLs. For example, if you allocate in one DLL and deallocate in the other. That won't work. But if the functions are self-contained, it should be ok.

[Peter_A_1]

Quoting - Steve Lionel (Intel)

The "static" concept does apply to DLLs - you can make a DLL that has no external dependencies on other DLLs. By default, a DLL project specifies that it links to DLL run-time libraries. You can change that to the static libraries ("Multithreaded" or /MT [/libs:static /threads])

The problem you may run into is if there's a need to share things such as allocated memory between the DLLs. For example, if you allocate in one DLL and deallocate in the other. That won't work. But if the functions are self-contained, it should be ok.

Many thanks that works fine in IVF9, and I will sendthe DLLto acustomer ASAP.

I guess I will have to look elswhere for a tip on what C++ threading option will do the same :-)

[Peter_A_1]

Quoting - Steve Lionel (Intel)

The "static" concept does apply to DLLs - you can make a DLL that has no external dependencies on other DLLs. By default, a DLL project specifies that it links to DLL run-time libraries. You can change that to the static libraries ("Multithreaded" or /MT [/libs:static /threads])

The problem you may run into is if there's a need to share things such as allocated memory between the DLLs. For example, if you allocate in one DLL and deallocate in the other. That won't work. But if the functions are self-contained, it should be ok.

Many thanks that works fine in IVF9, and I will sendthe DLLto acustomer ASAP.

I guess I will have to look elswhere for a tip on what C++ threading option will do the same :-)

[DavidWhite]

You may also want to look at my last post in the Thread "Calling dll from Excel CVF/IVF", as I have some example code for interfacing with Excel and comments about where to install the AddIns to minimize problems with workbooks that are linked to the DLL's

Regards,

David

[Steven_L_Intel1]

In C++, it's under "Code Generation". You want to select the Multithreaded (/MT) option.

[IanH]

Is there a merge module with the IVF redistributables?

[Peter_A_1]

Quoting - Steve Lionel (Intel)

In C++, it's under "Code Generation". You want to select the Multithreaded (/MT) option.

Thanks, I now havea C++ DLL which needsmy IVF DLL - but neither need the other "junk". Though the next question "is there a merge" might even get me down to a single DLL?

[Steven_L_Intel1]

We are working on an installer for the redistributables which ought to include a merge module (I have asked for that, anyway.)

As for a single DLL - sure. Just make either the C++ or Fortran project a static library rather than DLL and have it be a dependent project of the DLL project.

[Peter_A_1]

Thanks. I look forward to the new distibution tools .. though things are not too bad now that I can eliminate the "IVF" DLLS..

[Izaak_Beekman]

I have no experience with IVF on Windows, but I have found CMake’s capabilities to simplify making distributable bundles on Mac OS X superb and it looks like they have good support for Windows too. CMake might be worth looking into, especially if you want to be able to easily build your codes for Linux and Mac. On Windows you can tell CMake to use Visual Studio to build your project, or NMake Cygwin etc.

[Steven_L_Intel1]

For some reason, Peter A's old posts from years ago are resurfacing.....