visual studio linker warning LNK4098

Question

I have a dll project in which, when in Release configuration I build the project, I get the following warning:

MSVCRT.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

It's just a warning but I dunno if this should be taken into account.

For what I've found out, they are both multithread libs, normal and debugging versions. My dll uses multithreading and I can debug it, although I use boost:thread for it, so I really dunno if I need this Windows specific libraries for debugging or Release building...

Kind regards, Alex

Well, I did as BuschnicK suggested and using the /VERBOSE:LIB linker flag I found out that I was linking to these libraries in Debug configuration:

boost_filesystem-vc100-mt-gd-1_44.lib: libboost_system-vc100-mt-gd-1_44.lib: libboost_thread-vc100-mt-gd-1_44.lib: libboost_date_time-vc100-mt-gd-1_44.lib:

I had the same in Release config, mostly because I didn't specify then "explicitly". Thus, I changed them to this in Release:

boost_filesystem-vc100-mt-1_44.lib: libboost_system-vc100-mt-1_44.lib: libboost_thread-vc100-mt-1_44.lib: libboost_date_time-vc100-mt-1_44.lib:

That seem to worked but I was still getting the first warning, til I realized I had the _DEBUG preprocessor definition in my Release config too, removed it and it's working sweet now.

Thanks everyone for the help!!

Castorina

Answer 1

It sounds like you could be running a debug library and a release compiled library in the same build.

Go through your project options and select to use the debug versions of any 3rd party libraries you use.

Ment

The only boost library I'm using that requires lib linking is the filesystem, which, hsa two versions: – Castorina

Forget last comment: The only boost library I'm using that requires lib linking is the filesystem, which, hsa two versions: boost_filesystem-vc100-mt-gd-1_44.lib, boost_filesystem-vc100-mt-1_44.lib. I guess the first one is for multithreaded debugging, and second just mt. I've never specified in my linker options which to choose, it does it "automatically"...could this be the source of the problems? – Castorina

Answer 2

It says what the problem is right in the message if you read carefully: "MSVCRT.lib" vs "msvcrtd.lib"

Notice the added "d" in the second library name. What happens is that you are linking to the visual studio C++ runtime (MSVCRT) statically. One of your libraries is pulling the release version of that lib while another is pulling the debug version (hence the postfix "d"). The linker tells you that both libs define functions with the same name, are in conflict and thus one of them gets dropped automatically.

To fix this, go through the build settings of all your projects/libraries and make sure that they are using the same runtime libraries for all build configurations. Look in project properties -> C/C++ -> Code Generation -> Runtime Library. This should probably read "multi-threaded" for release builds and "multi-threaded debug" for debug builds.

Note that it is generally considered bad practice to link these libraries statically and that you should prefer the dynamically linked dll versions.

Bimbo

MSVCRT is already the dynamic version. You still have to link to this, although it's through an export library. msdn.microsoft.com/en-us/library/abx4dbyh(v=VS.100).aspx – Wacke

Sorry my bad. You are right of course. The rest of the answer should still be correct though. – Bimbo

Hmmmmm, I checked both configurations, in Debgug -> Multi-threaded Debug DLL (/MDd) and in Release -> Multi-threaded DLL (/MD), and I'm still getting the warning, do I have to use /NODEFAULTLIB:MSVCRTD.LIB for release configuration? – Castorina

No you shouldn't be using nodefaultlib. Take a look at all external libraries you are linking. At least one of those will pull in the conflicting runtime. – Bimbo

Hi again, I'm not using any external libraries besides some boost specific ones. I've changed both configurations: Debug and Release to point to the same lib: MSVCRT.LIB and now I don't get the warning. My only question now is...Will I be able to debug in case I need to? – Castorina

It'll work, but it's a hack. Debugging will work, but you'll loose some standard library debugging aids (checked iterators and other goodies MS put into their debug lib). You should keep looking for the root cause (i.e. who's pulling in the release lib in debug builds). – Bimbo

Why do you say it's a hack? I have linked to debug boost libraries and MSVCRTD.lib in my debug config and to release boost libraries and MSVCRT.lib in my release....where is the hack? I think I'm doing it in a pretty "standard" way, actually, what I had in mind, I never liked doing nasty things... – Castorina