default lib conflict

[wen]

I am using IVF 9.1.028 in a DOS Window.

After seeing a warning message:

LINK : warning LNK4098: defaultlib LIBCMT conflicts with use of other libs; use /NODEFAULTLIB:library

I inserted /NODEFAULTLIB:library as a linker option. Then I got the message

iFort: Command line warning: ignoring unknown option /NODEFAULTLIB:library

as well as the previous message

LINK : warning LNK4098: defaultlib LIBCMT conflicts with use of other libs; use /NODEFAULTLIB:library

The executable file was created in both cases.

That was when I ran nmake. If I ran iFort directly on a command line, I got a bunch of error LNK2005 such as

LIBCMTD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBCMT.lib(malloc.obj)

What should I do?

Wen

[Steven_L_Intel1]

/nodefaultlib is a linker option. If you put it on the ifort command, put it at the end and precede it with /link

However, that's usually the wrong solution to the problem. You have some code compiled with the debug libraries and some without. The library option needs to be the same on all compiles.

[dboggs]

I have essentially (I believe) the same issue in my project. This contains only .f90 files--one main, several subroutines, and a couple of modules. The debug build works fine. Attemp to build a release gives errors of the form

LIBCMTD.lib(dbgheap.obj) : error LNK2005: _[various things] alreadyh defined in LIBCMT.lib(various.obj)

I realize this is a library mismatch, but I don't know where, and as far as I know how to control it all of the files are compiled with the same library. The command line for all files is

/nologo /module:"Release\\" /object:"Release\\" /Fd"Release\vc100.pdb" /libs:qwin /c

I am using Visual Studio. What is the problem and how do I fix it? I have found a discussion in the documentation about mismatched libraries and scanned this forum finding lots of similar problems, but I can't find an understandable solution.

[mecej4]

At least one of the object files that you link together (or/and at least one of the objects in a library that you link with) was compiled with debugging specified (/MTd or /MDd). You can use Dumpbin to find which one, and rectify. 

[dboggs]

I'm pretty sure that EVERY file was compiled with the same settings--the ones I identified above. I don't know how to use Dumpbin. Shouldn't it be enough to compile each file individually using VS, checking the properties each time? I've already done that. And if
Dumpbin does tell me which files had debugging specified, how would I eliminate that? It already looks like there is no /MTd or /MDd setting! Am I looking in the wrong place?

[andrew_4619]

I would do a clean and a full rebuild first. You can run dumpbin from the fortran cmd prompt. Read support.microsoft.com/kb/177429‎ which Provides a description of the DUMPBIN utility. Includes some of the output for each DUMPBIN command-line option.

[dboggs]

Thanks everyone but nevermind, I found the problem. For the record, unbeknownst to me (carelessness!) my project links to routines in a static library, the location of which was in the library project's \debug folder instead of its \release folder.

Correct me if wrong, but it seems the preferred practice would be to always link to the libproject.obj file resulting from a release build. This seems to work without a library conflict (don't know why). The only disadvantage is the debugger will not be able to step into the library routine--which is not normally expected anyway.

[Steven_L_Intel1]

Another approach is to build the static library with the Fortran > Libraries > Disable OBJCOMMENT Library Names property set to Yes. This will then require the executable project to supply the libraries, which a Fortran project usually does.

But usually, a release executable is built with a release library. If the library project is a "dependent project" of the executable, it will be built and linked in automatically.

[dboggs]

I misspoke in my previous entry: a release-build library obj DOES NOT ALWAYS link correctly with a project debug build. Sometimes yes, sometimes no.

So, I am interested in the "dependent project" method, but I don't understand it. Please some more info Steve:

1. Is the library project .f90 file group specified as a dependency, so that they will be compiled along with the project? Is this what "automatically" results in release library versions for a release project, AND debug library versions for a debug project?

2. How do I specify this dependency (sorry about my ignorance)? Using Visual Studio. I can see that by selecting the Solution in Solution Explorer then Project properties, I get a window that shows Project Dependencies, but it is empty and there is no way to enter anything.

I would really appreciate instructions, or at least point me to the Documentation section that describes this.

[jimdempseyatthecove]

When I have conflicts like this, I use the ignore specific library option to ignore LIBCMTD or LIBCMT as the case may be. Sometimes you may have multiple MS libraries to ignore. What is happening here is you likely have different object modules specifying to load the different varient of a library (multi-threaded debug or multi-threaded). Either library will do (unless you specifically want one over the other).

Jim Dempsey

[Steven_L_Intel1]

My general comment on this issue is that the "ignore library" approach should be your last choice, as it often creates other problems that are difficult to diagnose (all to do with C code - Fortran code tends to not be an issue.) You can almost always solve the problem by making sure that all compilations are set to use the same library type. For Fortran static libraries, it is often helpful to set the option to not have ANY default libraries (in Fortran this is /libdir:noauto), but the C compiler generates different code for the different choices (Fortran doesn't) and if you link C code compiled one way with an executable compiled another, you can get bizarre link errors.