Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Confusion about libraries

scitec
Beginner
637 Views

Hello, Group,

Sorry if this is a duplicate post. I tried to post it a while ago, but it didn't appear, so this is a second attempt.

I am currently trying to resolve a mysterious problem in a Fortran DLL that has led me to look at the libraries that are being linked to it. I'm finding the information about this to be a bit confusing, and not completely correlated with what is actually happening.

From the documentation I have seen, I expect that if I set the Project properties Fortran+Libraries+Runtime Library option to "Single-threaded DLL" then the resulting DLL should link to libifcorert.dll. But if I inspect the dependencies of the resulting DLL, I find that it is referencing libifcoremd.dll (the Multithread DLL library) instead.

If I set the option to "Debug Single-threaded DLL" then the reference is libifcorertd.dll, as expected. Similarly, if I set the option to "Debug Multithread DLL", libifcoremdd.dll is referenced.

So my first question is: Am I doing something wrong here, or have I perhaps misinterpreted the documentation?

My second question is: Which library (single or multi-threaded) should I be using? The code in the DLL is inherently single-threaded, but I remember reading somewhere that I must match the types of libraries in use, and there does not appear to be a single-threaded DLL C run-time library. (Could this actually be the answer to my first question?)

And finally, there seem to be two different C run-time libraries: msvcrt.dll and msvcr71.dll. The latter is included as a direct reference when I build my DLL, and the former is shown as a dependency of libifcoremd.dll. The article at http://msdn2.microsoft.com/en-us/library/abx4dbyh(vs.71).aspx mentions potential problems if both of these are in use. What must be done to ensure that there are no problems or conflicts between these two?

Any pointers or guidance will be most gratefully received.

Cheers,
Randy

0 Kudos
4 Replies
Ilie__Daniel
Beginner
637 Views

Randy,

To answer you first question:

Try adding the compiler option /MDs in order to link against libifcorert.dll. See if that works.

Generally, DLLs are required to be thread safe so they automatically mutithreaded.

Hope this helps a little,

Daniel.

0 Kudos
Steven_L_Intel1
Employee
637 Views

It is not the case that DLLs are required to be thread-safe. You must select the multithreaded DLLs to get thread safety.

In the case where you are getting libifcoremd.dll instead of libifcorert.dll, please go to the Fortran>Command Line property page and tell me what options it shows there.

msvcrt.dll is the MSVC 6 DLL and is also a system DLL nowadays in Windows. msvcr71.dll is the one from VS2003. There is no problem having both as long as the reference to msvcr71.dll comes from the Fortran DLL and you are not using C code some ofwhich uses msvcrt and some using msvcr71. When one links to the DLL libraries in VS2003 you get msvcr71.dll.

0 Kudos
scitec
Beginner
637 Views

Hello, Daniel,

Thanks for your answer.

Yes, explicitly adding /MDs to the compiler options on the command line causes libifcorert.dll to be linked in. I thought that selecting "Single-threaded DLL" as the Run-time library option would have done this implicitly (silly, eh?)

But I am still confused about the single vs multi-threaded question. Is there ever any reason/advantage to creating single-threaded DLLs (even in a case like mine wherethe application is fundamentally single threaded)?

Cheers,
Randy

0 Kudos
scitec
Beginner
637 Views

Hi, Steve,

Thanks for those clarifications.

The command line "All Options" box reads:

/nologo /Zi /Od /include:"..Include Files" /warn:declarations /module:"..aa_Modules/" /object:"$(INTDIR)/" /traceback /check:bounds /c

and the "Additional Options" box reads:

/dll /debug-parameters

If I add "/MDs" to that as Daniel suggested, then the libifcorert.dll gets linked in.

Cheers,
Randy

0 Kudos
Reply