Using .lib from a .dll

[mini_minsaas]

Hi I have a major headache now, after 3 days of searching for an error that doesn't even exist on my computer. I have solution in Visual Studio 2005 with several projects, including one C# project (the GUI) and one Intel Fortran project set up as a Dynamic-link Library (dll). My problem is that this fortran project has some calls to a static library (myFile.lib), witch is included as a resource in the project. It compiles, and runs smoothly on my computer, but when I take out the program and try to run it on any other computer, the dll fails. I also have other dll's that doesn't call any .lib files, and they works fine.

If I comment out the calls to the .lib-file, it all works fine, but needless to say, I need the calls to work. Anyone have any idea's what I might do wrong? Is there any settings I need to do in Visual Studio to make sure the .lib is "included" in the dll?

Fast reply's are appreciated :)

[mini_minsaas]

Please....

Anyone have any idea? I'm really desperate, and need an answer as soon as possible! Has anyone made a dll that uses a *.lib file?

Does it work on other computers too?

[joerg_kuthe]

Maybe you give us some more information about the problem:
What error message?
What is the name of the .dll?
What is the name of the .lib?
Is the .lib you are using an import library (to a .dll) or a real static library?
...

[Jugoslav_Dujic]

Seconded. "Dll fails" is a vague and utterly unusable problem description.

Having a .lib linked into a dll is not anything special, and probably has nothing or little to do with the cause of your problem.

I might venture a guess that the target computer is missing some of other required dll's, which you can verify using dependency walker on the target machine, but it's a wild stab in the dark. Another possibility are uninitialized variables somewhere in the code. The third...

Morale: to be able to receive some help, you have to give us some data to work with.

[mini_minsaas]

Thank you for that last reply. It solved my problem, at least found one solution.

The tracer-program said that "LIBMMD.DLL" was missing, and that is correct, but...

I have no idea what it is, why I need it, or most importantly, why Visual Studio doesn't copy this to my release/debug directory?!

Edit: Is there any way to force Visual Studio to copy all needed dll's to the output directory?

[Jugoslav_Dujic]

Libmmd.dll is Intel's math library dll. It's likely absent on target computers which don't have IVF installed.

The VS doesn't copy the dependent dll's to the output directory because that defeats the purpose of dll's, which is being shared among several applications (among other things). Instead, you have to redistribute the dll's to the target computer, either in a path's folder (like WindowsSystem32 or in the application's folder).

You can avoid the dependency on Intel and VC++ dll's by means of static linking against the run-time libraries -- go to Project properties/Fortran/Libraries/Run-time library and pick one of non-dll versions; then rebuild and check the dependencies with Dependency Walker. However, note that, in presence of a .lib, it's not guaranteed to work... (if you still see the dependency on Libmmd.dll after the rebuild, please report back).

[mini_minsaas]

Thanks! That solved the problem :)

[DavidWhite]

Jugoslav,

If I link to thenon-DLL libraries, as you suggest, can I completely eliminate having to distribute runtime libraries with my App? I have been routinely distributinglibifcoremd.dll,libifcorert.dll, libifportmd.dll and libmmd.dll.

Thanks, David

[Jugoslav_Dujic]

Short answer: Yes.

Long answer: Dll version of the RTL, however, is necessary in the following cases:
* if the calling Fortran application and the Fortran dll share I/O unit numbers and I/O units
* if the allocation and deallocation of the same variables happens in different modules (.exe and .dll)
* (maybe something else I forgot)

In all other cases, you may statically link with the RTL, obviating the need for redistribution of libif*.dll, (and obviously, on the expense of executable's size).

[DavidWhite]

Jugoslav,

I think I satisfy all the requirements for static linking. However, when I try to link against static libraries, I get more than 200 errors against the Intel libraries ...

libifport.lib(random.obj) : error LNK2001: unresolved external symbol __fltused

Compiler Options are

/nologo /Oy- /fpscomp:nolibs /stand:f95 /warn:declarations

/warn:unused /warn:truncated_source /module:"c:DevModules"

/object:"c:DevIntermed/" /traceback /check:bounds /check:uninit /check:format

/check:output_conversion /libs:static /threads /winapp /c

Have I missed something?

Thanks,

David

[Jugoslav_Dujic]

Hmm. __fltused comes from libcmt.lib -- the VC++ static run-time library -- which ought to be pulled in in any case.

Why is that /fpscomp:nolibs there? However, it doesn't make a difference for me.

I think that linker options would be more interesting -- do you perhaps have an /ignore: left over from the ancient times? In any case, try linking with /verbose (Linker/General/Show progress) and try to deduce why libcmt.lib is not there.