- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page