DLL Dependencies? ImageHlp.dll?

[Darrell]

I'm looking at our large Java-JNI-C++-Fortran project. We are phasing out / retiring VF6 and upgrading to VF11.1. Using Dependency Walker, I see our debug DLL is dependent on not only the Microsoft C & C++ runtimes along with the Intel Fortran runtimes but also ImageHlp.dll

I googled ImageHlp.dll and it's either an important operating system file or malware! You can't believe everything you read on the Internet, right?

* What is ImageHlp.dll used for?
* What call did my program make that made it dependent on it? It's not an image processing calculation? I would have only expected the use of print, write, and sqrt in our calculation not any fancy libraries.
* Is there a compiler switch to remove this dependency?

Furthermore, it appears that according to the compiler documentation for /DLL, that I can no longer make a DLL that's not dependent on the C & Fortran DLLs? In other words, we'd like to setup our solution/projects to make C++ wrapped Fortran DLLs that are staticly linked to the C & Fortran runtimes that do not need to call the msvcr##.dll and libifcore*.dll Is this possible or should we be sure to makee the install program redistribute all these files? We're just trying to avoid "DLL Hell". I'm learning more about manifests that I ever wanted to.

/DLL "overrides any previous specification of run-time routines to be used and enables the /libs:dll option."

We're looking forward to porting to 64-bit to join the 21st century. Right now we're starting to get out of memory errors: "not enough memory to load dependent libraries". We're tried various combinations of Java stack/heap size settings on Windows XP 32-bit.

The project is currently a mismash of DLLs which all used different versions of Visual Studio so Process Viewer shows multiple runtimes loaded at once! Hopefully when we all get up to Intel VF11.1 that will help.

Even the latest version of Java 6 uses msvcr7 instead of Visual Studio 2005 (v8) not to be confused with 2008 or the new not ready for Fortran VS2010?

Thanks. If anyone has a perscription for my DLL Headache, it's Dr Fortran! :-)

[abhimodak]

I think static linking is possible by using /libs:static.

Abhi

[Steven_L_Intel1 · Accepted solution]

In the Fortran project properties, set Libraries > Use Runtime Library to "Multithreaded". I recommend this if your DLL is not going to be called from Fortran or C/C++.

imagehlp.dll is used to support traceback.

[Darrell]

Good answer! Image = debug trace back not bitmap graphics.

I think I've successfully attched our compiler settings following the instructions in your link. We've been using multi-threaded from day 1 with VF6.

As far as you know, it is possible to staticly link the DLL to the runtimes so they are not dependent?

I thought the Visual Studio Project Settings were forcing me to set it to MultiThread DLL when /DLL is used to create a DLL per that line in the manual I quoted?

I've just installed the latest VF11.1.65 update 6 if that helps? We need to upgrade from VC2005 to 2008 while waiting for 2010 support with VF too.

The main entry point in our DLLs are called from java via JNI to the C++ wrapper that calls the Fortran. However, more and more of the Fortran routines are calling sub subroutines in other (sometimes pure Fortran) DLLs.

To save our sanity, we're hoping to find the perfect set of compiler settings and use them everywhere? Is that a sane goal?

[Steven_L_Intel1]

For a self-contained DLL that is not called from Fortran or C/C++, you can certainly link to the static libraries. The default, when a DLL project is created, is to link to DLL libraries because you want to avoid having two or more copies of the same libraries in the image address space.

If your DLL is calling other Fortran DLLs, then you really should be linking to the DLL libraries to avoid errors.

Unfortunately, I can't recommend the goal of using the same settings for all applications. Sometimes an adjustment is needed. Most of the settings you can leave alone - the defaults are good.