• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 292
  • Last Modified:

Linker warnings in Release Build

I am using VC++ 6.0 on an NT machine.  When I build for release I get the following error:
LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs; use /NODEFAULTLIB:library
If I then want to run this on another machine I have to copy msvcrtd.dll onto that machine.  What is up with this.  I have made many changes to the project settings to no avail.  If I use /NODEFAULTLIB I end up with 100's of errors.  Thanks for your help
0
BigOne
Asked:
BigOne
  • 2
  • 2
  • 2
  • +3
1 Solution
 
chensuCommented:
It seems that you mix up debug version libs and release version libs.
0
 
mandhjoCommented:
Do you link in several different libraries?  It is probable that you are linking in a library that was built in debug mode (so it is expecting the debug libraries to be linked in).

For example, your program links in cool.lib which was build in debug mode.  When you build your program in release mode, it is trying to link in the msvcrt.lib (release version).  It is also linking in cool.lib (which was built in debug mode).  cool.lib is expecting the debug version of the msvc runtime library (msvcrtd.lib).

So, your exe is compiled and linked and first grabs the release version of the runtime library (msvcrtlib).  It then gets around to linking in cool.lib which tries to bring in the msvcrtd.lib.  Since the same functions are defined in msvcrt.lib and msvcrtd.lib, you get the linker warning and are required to have the msvcrtd.dll on the other machine.

Make sure all libraries to be linked in are also built in release mode.
0
 
Billy_PilgrimCommented:
hey - i fought this one for hours last night, only in version 5.0.  maybe the same bug.

i wasn't importing any libraries extra (i just took my source and let it build a default project)

but if you go into the link tab under project settings you can add the text /verbose to the long list of options in the edit box on the bottom--

it will print A LOT of info in the output window during the link phase- and you can see where it stopped linking and attempt to remove that function from your program.

mine was bombing on isdigit() so i just rewrote the code to manually check for isdigit instead of using the library function.  and then it worked correctly.

note - several times i deleted every file in the project and directories except my source file and rebuilt my project-- so i know i wasn't trying to link in anything from debug mode.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
cyberfrankCommented:
Hi!

The reason why You get those errors is, that u use some other libraries, which are compiled with different project mode : debug/release multi/single threaded. In one project (when You build the exe i.e.), you have to have all libraries compiled using same  type of libraries. I suggest that You check Your project settings for all libraries what you use!
Project -> Settings for win32 Release -> C/C++ -> Code Generation -> Use-RunTime library -- here You have to set same for all You libraries!!

CF
0
 
mikeblasCommented:
Billy_Pilgrim> maybe the same bug

It isn't a bug.  It's operator error, for all the reasons that mandijo describes.

Note that the problem isn't limited to LIBs, though. It can be caused by including an OBJ, too, that was previously built for debug and trying to mix that with other release-build OBJ files.

..B ekiM
0
 
Billy_PilgrimCommented:
no, it is not operator error.

i am well familiar with the workspace files.

if you open them as text, they list all included libraries and compiler options.

i have gone through every option to verify the correctness of the import libraries based on debug / release mode for single and multi thread ; it is a bug in versions 4.2 and higher of vc++
0
 
mikeblasCommented:
Billy_Pilgrim> if you open them as text, they list all included
 Billy_Pilgrim> libraries and compiler options.

I'm afraid they don't. OBJs, and OBJs included in LIBs, can include a default library record. When the linker eats a given OBJ, it may notice that default library record is there and additionally link to that library. That library won't necessarily appear in the workspace file. The linker will ignore default libraries if you give the /NODEFAULTLIB option, and you can use this same option to ignore a specific default library.

Of course, using /NODEFAULTLIB to work around this problem is ill-advised, as is simply ignoring the error. Code built for debug will expect to link to debug-enabled libraries. Those libraries will anticipate debug-oriented structures, which are usually larger and have different packing. They'll expect the debug-based memory management routines, too.

 Billy_Pilgrim> it is a bug in versions 4.2 and higher of vc++

This mechanism has been in place since the sixteen-bit linker, and wasn't added in VC++ 4.2. The behaviour is completely by-design.

The operator error here is simply mixing debug- and release-built objects and/or libraries. Don't do it: it won't work. And that's what this linker error is intended to draw attention to.

If, despite all this advice to the contrary, you still believe it's a bug, please provide a minimal reproduction case.

..B ekiM
0
 
BigOneAuthor Commented:
Thanks for all your help.  I am linking in about 20 different .Libs and it is the Debug/release conflict.  I am awarding the points to mandhjo buecause his answer was the most descriptive and complete.
0
 
mandhjoCommented:
Thanks and glad I could help.
0

Featured Post

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

  • 2
  • 2
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now