Simplest way - just drag and drop the file onto the "Source files" folder in the VS project. You can also use Project > Add to project > Files... , or the hard way, put the full path to the library in Properties > Linker > Input > Additional Dependencies.

The messages mean that the module F2KCLI is referencing two external functions, F2KGETCL and F2KGETEXE that it can't locate. I am not familiar with this package's organization so I don't know why that should be. However, there is no need to use F2KCLI - Intel Visual Fortran supports GET_COMMAND, GET_COMMAND_ARGUMENT and COMMAND_ARGUMENT_COUNT from Fortran 2003. No additional declarations are needed to use these.

Steve, I routinely add my library files to a project using your "simplest way"--dragging and droping the files, or better yet adding a reference to them to the project. But, I often run into problem because, as best I can understand it, different versions of the library build are needed depending on whether I am building a debug or release version of my project. Failure to account for this leads to many linker errors due to library conflicts. From discussion in another thread on this subject, I understand that this is normal and the best way to circumvent it is to add the library using the "additional dependencies" method, but I don't yet have enough experience to know how successful this is.

With this in mind, would you still recommend your "simplest way" or not?

I find this whole subject very confusing. I feel I have received conflicting information from various persons on this forum. The subject gets even more complicated when there are modules involved. The Intel documentation has just a little to say on this subject, but I find it uncomprehensive (overly simplified) yet too difficult to follow (use of jargon) to be very helpful.

It would be wonderful to see a comprehensive, authoritative discussion of this issue somewhere.

There are two important cases where one needs the debug version of a library:

When the routines in the library itself are being debugged

When one wishes to step into a library routine or set a breakpoint at a text symbol in the library to check the values of the arguments passed.

There may be others, but I have not run into them. If your user-developed or third party libraries are trustworthy, why do you need debug versions of those libraries? I have never found any need for debug versions of the Intel Fortran and MSVC libraries or their voluminious PDB files.

As with any optional software, IDEs have their costs and benefits which you have to evaluate in order to decide whether an IDE should be a part of your professional life. Personally, I use a language-aware text-editor, Make/Nmake, and a command line environment for my development work. Learning how to do use them took a few weeks (several decades ago), and most things work to my satisfaction. However, I will not push my preferences on others. Your choice.

The DLL versus static C runtime choice is the other (another?) dimension in the selection of a library variant. There can also be things like whether the library uses or is aware of things like OpenMP. Compile the library with IPO enabled and then you need to start worrying about specific compiler versions!

(The debug C runtime does a heap of extra checking for things like memory allocation, etc, so it can be pretty useful when running debugging type builds to have it as the underlying C runtime for everything. A third party library might be very reliable, but abuse of it (erroneous calls, etc) by the client program can still result in memory corruption or similar that a debug runtime will flag. A single, consistent C runtime is also pretty important when you have things like IO or memory allocation/deallocation otherwise potentially being shared across runtimes.)

I tend to go the path of putting the libraries under Linker > Input > Additional dependencies (or Librarian > General > Additional dependencies if I'm incorporating the contents of a library that is external to a project into a library that is built by the project). I find that this is a little more convenient for the different build configurations, and also lets me move the potentially machine dependent location of libraries/library search directories to machine dependent things like environment variables and "central" visual studio/ifort options (I try and keep machine dependent paths out of the projects). It is a little bit less transparent though. If you add a new project configuration (for example, I often have Debug, Debug-OMP, Release, Release-OMP, some sort of static analysis config) you need to go through and make sure the new configuration picks up the necessary libraries, which is something I invariably forget.

I think you can still use the "library as a source file" approach for different configurations, you simply add each variant of the library, and then suppress in each configuration (via the Excluded from build property) the ones that you don't want. Looks a bit weird though, having very similarly named libraries sitting in your solution explorer. I'm pretty sure I used to do this several years back, but to be honest I can't find any examples at the moment.

I don't know if you'll find an "authoritative discussion" because I think the decision comes down somewhat to personal preference and some tradeoffs that depend on your specific situation. Alternatively I've just been living in blissful ignorance of a better way.

To mecej4, regarding what the need is for two versions of a library: The debug version is needed when I build a debug version of my application, and the release version is needed when I build a release version of my application. Otherwise I get a pile of linker errors. It is quite cumbersome to maintain two versions and to remember to link with the right one.

Actually this is not ALWAYS true, I work on different computers with slightly different versions of IVF and VS. On one machine I find that a debug build can use EITHER the debug library or the release library (when debugging I can't of course step into the library routine, but this is expected and hence OK). If this were always the case it would greatly simply the situation. But it fails on the other machine (i.e. a debug project will not link with a release library). Lori Menard once helped me with this problem (on this forum) and got into things like the necessity of checking that the library linked with is multithreaded or not, but I didn't completely understand that explanation and it seems the default VS configuration may not be the one that is needed, at least in certain situations.

If you are developing the library, then I recommend making the library project a dependent of your main project. This will get you the proper configurations for debug and release.

If you are simply using a library someone else provides, then the other methods I mentioned work. If the library is all Fortran, then I usually recommend that it be built with the /nolibdir option (Fortran > Libraries > Disable default library search rules > Yes). If the library has some C/C++ in it, then you need to know which "code generation" option (/MT, /MD, etc.) it was built with and make sure your project specifies the same one.

What exactly does this mean? I know I can make a specific LIBRARY a dependency: Project > Properties > Linker > Input > Additional dependencies, but in my experience I have to specify the exact *.lib and its path. Are you saying make the library PROJECT a dependency using this same property? What exactly do I type into the dependency field?

And when someone else provides the library, I still have trouble linking to my project unless they provide both a debug and a release version, so that I can specify the appropriate one when I build a debug or a release version of my project. I do have some influence over how they build it (in fact I have to tell them how to build it), so what can they do to provide a single library.lib file that will work for all my builds? (I had been led to believe that a release library would work for a debug project build, with the simple limitation that I would not be able to step into the library routines when debugging--which would be fine with me--but it doesn't always work.

Right click on your executable project, select Project Dependencies. In the Dependencies tab, you'll see a list of the other projects under "Depends on". Check the box by the library project.

This will cause Fortran projects to automatically link in the output library of the dependent project, and will select the proper one for the configuration. Some caveats are listed in the release notes under the topics of VS2010 and VS2012.

If you're manually adding .lib files, then you'll have to select the appropriate one for each configuration.

I don't have a Project Dependencies option, or anything else that leads to a Dependencies tab or Depends on. See attached file VSscreencap.doc. I think I need help with the right foot on the first step.

Well I'll be! Please bear with me, I have never worked with a solution containing multiple projects!

So now I have a project MYPROG that calls a couple of subroutines from a static library MYLIB. I have added both projects to my solution. Visual Studio tells me that the project MYPROG depends on project MYLIB. (and I believe this because if I rebuild the solution it will compile MYPROJ and all of the routines in MYLIB, then try to link it) But it will not link: any library routine that I call results in an unresolved external. Is there something else I need to do?

Just to confirm things using another method, I can explicitly add MYLIB\DEBUG\MYLIB.LIB to project MYPROG, and everything works OK.

OK I see it now. I thought it was enough to have the intended project appear in the list of dependent projects--didn't realize that leading square thing was a checkbox, and that I had to check it! Duh! (Would have been more obvious if there were other projects in the list.) Thanks for putting up with me.