When linking my dll in release build I get -
1>LINK : warning LNK4098: defaultlib
'mfc80d.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib
'mfcs80d.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib
'msvcrtd.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
adding /VERBOSE, I see the following (snippet):
...
1> Searching D:\Microsoft Visual
Studio 8\VC\atlmfc\lib\mfc80d.lib:
1>
Found "public: virtual __thiscall
AFX_MODULE_STATE::~AFX_MODULE_STATE(void)"
(??1AFX_MODULE_STATE##UAE#XZ) 1>
Referenced in mfcs80.lib(dllmodul.obj)
1> Loaded
mfc80d.lib(MFC80D.DLL)
1> Found "long stdcall
AfxWndProc(struct HWND__ *,unsigned
int,unsigned int,long)"
(?AfxWndProc##YGJPAUHWND__##IIJ#Z)
1>
Referenced in mfcs80.lib(dllmodul.obj)
1> Loaded
mfc80d.lib(MFC80D.DLL)
...
If I'm interpreting this correctly, it means the linker somehow resolves calls from the (optimized) library mfcs80, as calls into the (non-optimized) library mfc80D. How can this be??
When I add /NODEFAULTLIB:mfc80d.lib the warnings are gone, but I'm not quiet with it yet. As an aside, the module does indeed suffer from sporadic inexplicable crashes on incremental links, that are solved only by a re-build. I'm using VS2005.
[Edit:] Changed the title to include DEFAULTLIB, hopefully better focusing the subject. I do see an explicit line saying
processed /DEFAULTLIB:mfc80d.lib
in the /VERBOSE output, among many other (non-debug) default libs. Where does it come from? how can I fix this?
Thanks!
You should check the run-time library settings for your projects, sounds like you have a mismatch. In your project settings under C/C++ > Code Generation > Runtime Library, you have the choices:
Multi-Threaded
Multi-Threaded Debug
Multi-Threaded DLL
Multi-Threaded Debug DLL
It sounds like some of the projects in your solution may be using a Debug version while others use the Non-Debug version. Or alternatively, some projects may be using the Debug version while others are using the Debug DLL version. For a given solution configuration, you want all of the projects to use the same setting.
The issue was resolved much later - I post it up here in case it helps somebody someday.
It turned out to be a wrong precompiled header path: release configuration pointed to the default debug PCH path. So on transition from debug to release, a build would drag in all the debug PCH contents - apparently including some debug versions of MFC #pragma (comment "lib..") (included in afx headers). A clean build would rebuild the PCH correctly, but again into the debug folder - thereby causing identical problems on transition back to debug build.
It means that one of the dependent dlls is compiled with a different run-time library.
Project -> Properties -> C/C++ -> Code Generaion -> Runtime Library
Go over all the libraries and see that they are compiled in the same way.
More about this error in this link:
warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs
Related
I am trying to get a Visual Studio 2017 project to link, but I'm stuck on the following linker error:
LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
I've read questions on what the cause could be, but I couldn't come to a solution for my project.
The details are that, due to an external component we have no control over (component A), this Visual Studio 2017 project is forced to use the v14.13 version of the C++ toolchain, i.e. not the latest one (v14.14). However, the latest release of another external precompiled static lib we have no control over either (component B), is built with the v14.14 version (I checked via a dumpbin extract of the debug version of the lib). Switching my project over to the v14.14 toolchain indeed makes the link error go away on component B, but this unfortunately isn't a solution for me due to component A. Taking an earlier version of component B isn't desirable either, since we need the functionality in the latest release...
However, what strikes me, is that the /Ot ("optimize for speed") flag has been around since the middle ages... Why wouldn't v14.13 recognize it? Or is it just an (awkwardly manifested) matter of a mismatched obj file layout due to the version differences? And, probably related, what does the 'p2' stand for anyway?
Update
I've checked the linker output by using the /verbose flag, and all seems normal (3600 lines of Searching <lib>, Found <function>, Referenced in <obj> and Loaded <lib>).
Right up until the end that is, where I get the following 6 lines:
1> Searching C:\PathToExternalLib\TheirStatic.lib:
1> Found UsedFunctionName
1> Referenced in MyOwnStatic.lib(MyOwnCompileUnit.obj)
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "MyProject.vcxproj" -- FAILED.
And that's that.
When visiting the command line setting of the link properties of the project, the only thing listed is (broken up in separate lines for convenience):
/OUT:"MyProject.dll"
/MANIFEST
/NXCOMPAT
/PDB:"MyProject.pdb"
/DYNAMICBASE "C:\PathToMyStatic.lib"
/IMPLIB:"MyProject.lib"
/DLL
/MACHINE:X64
/PGD:"MyProject.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"MyProject.prm.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"C:\PathToExternalStaticLib"
/LIBPATH:"C:\PathToAnotherExternalStaticLib"
/TLBID:1
So no trace of any -Ot flag there as well...?
I had this problem. LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
while building a project with Visual Studio 2015.
I had to rebuild any library or sub library the project linked to which were built with Visual Studio 2017.
Once I rebuild the dependent libraries with Visual Studio 2015 the first project was able to link against them.
project
--------\
---------lib1(unable to rebuild lib1 until its dependencies were also rebuilt with VS2015
--------------\lib_linked_by_lib1_which_was_build_with_VS2017_and_had_to_be_rebuilt
--------------\another_lib_which_had_to_be_rebuilt_for_lib1_with_VS2015
--------\lib2
--------\lib3
After several hours of stretching my hairs, I can't figure this out. In Debug version, it is working fine. But in release mode, I am getting this warnings and eventually an runtime error. As far as I know, these libraries are debug versions. Why is my release build looking for these libraries and how can I stop it? FYI, I looked at settings and project files to find a clue in vain.
LINK : warning LNK4098: defaultlib "mfc42d.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "mfcs42d.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "msvcrtd.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
Impossible to tell without more information why your project is including these. My guess is that you are linking with a debug configuration of some other library, which is pulling in those dependencies. If you increase the verbosity of the linker settings then it may show you which files are including them.
The fix though is given in the error message. Add /nodefaultlib:mfc42d.lib/nodefaultlib:mfcs42d.lib /nodefaultlib:msvcrtd.lib to the linker arguments.
I got the c++/cli dll to link to a vc++ dll, but when trying it with the static version of the vc++ lib there are a bunch of linker errors. I want to use static so I dont have to copy all of the other vc++ dll files into my main c# project, which uses the c++/cli dll.
The vc++ library has the following properties:
*built in vs2008
*Static library
*uses MFC in a static library
*No common language runtime support
the c++/cli library has these properties:
*built in vs2010
*Dynamic Library
*Use of MFC in a shared DLL
*Common Language Runtime Support
*linker->input contains the vc++ lib file
I tried linking the vc++ lib it after building it in vs2010 but that didn't help.
So I get like 90 LNK2005 errors like these from nafxcwd.lib:
1>nafxcwd.lib(dlgprop.obj) : error LNK2005: "public: struct _PROPSHEETPAGEA & __thiscall CPropertyPage::GetPSP(void)" (?GetPSP#CPropertyPage##QAEAAU_PROPSHEETPAGEA##XZ) already defined in mfc100d.lib(mfc100d.dll)
then like 30 or so of these:
1>libcmtd.lib(sprintf.obj) : error LNK2005: _sprintf already defined in msvcrtd.lib(MSVCR100D.dll)
then three LNK4098 warnings:
LINK : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib 'nafxcwd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib 'libcmtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
then I get this last error:
libcmtd.lib(crt0.obj) : error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
I looked up the LNK4098 warning on msdn and the solution was to add the conflicting libraries to the IgnoreSpecific Default libraries entry in the linker input settings, but this did not help.
Thanks,
alex
You can't link (C++) libraries build with different version of the VS compiler (sometimes it may accidentally seem to work but you'll usually get hard to diagnose crashes later on). Additionally, your errors seem to be typical of selecting different CRT configurations (single/multi-threaded, debug/release etc).
When compiling a win32 console project with GLFW in Visual Studio 2010 SP1, I am getting the following warning for debug configuration:
Warnung 1 warning LNK4099: PDB "vc100.pdb" wurde nicht mit "GLFW.lib(enable.obj)" oder an "C:\path-to-project with-spaces\World\Debug\vc100.pdb" gefunden; Objekt wird verknüpft, als ob keine Debuginformationen vorhanden wären. C:\path-to-project with-spaces\World\World\GLFW.lib(enable.obj) World
13 more for GLFW.lib(enable.obj), GLFW.lib(glext.obj), GLFW.lib(image.obj), GLFW.lib(init.obj), GLFW.lib(input.obj), GLFW.lib(stream.obj), GLFW.lib(tga.obj), GLFW.lib(win32_enable.obj), GLFW.lib(win32_fullscreen.obj), GLFW.lib(win32_glext.obj), GLFW.lib(win32_init.obj), GLFW.lib(win32_time.obj), GLFW.lib(win32_window.obj), GLFW.lib(window.obj)
And last but not least:
Fehler 15 error LNK1104: Datei "C:\path-to-project with-spaces\World\Debug\World.exe" kann nicht geöffnet werden. C:\path-to-project with-spaces\World\World\LINK World
The release configuration is compiling. This is probably still not enough information for solving my problem, but I would appreciate an explanation for why this can happen.
I don't know what the warnings/errors are saying because I don't know any German whatsoever, but generally if something compiles/links for release but not debug (or vice-versa) this means you're linking to the wrong libraries for the one that isn't working. Are there specific debug libraries (.dll's or .lib's) for the GLFW library? Sometimes you have to tell VS to use one for your project's release configuration and a different one for your project's debug configuration. Check for something like glfw.lib and glfw_d.lib, where the _d would indicate the debug library.
Or if you could supply the English translation of the link warnings/errors I might be able to help more.
Good luck!
Whenever building a project with VC++ fails, it's best to consult the MSDN with the error code. In your case http://msdn.microsoft.com/en-en/library/b7whw3f3(v=vs.80).aspx
Linker Tools Warning LNK4099 PDB 'filename' was not found with
'object/library' or at 'path'; linking object as if no debug info The
linker was unable to find your .pdb file. Copy it into the directory
that contains object/library.
To find the name of the .pdb file associated with the object file:
Extract an object file from the library with lib
/extract:objectname.obj xyz.lib.
Check the path to the .pdb file with dumpbin /section:.debug$T
/rawdata objectname.obj.
You could also compile with /Z7, so the pdb doesn't need to be used,
or remove the /DEBUG linker option if you do not have .pdb files for
the objects you are linking.
I was already using the right lib for debug configuration but was not only linking to GLFW.lib but also to GLFWDLL.lib. You can either compile GLFW into you executeable by using GLFW.lib or use a DLL by linking to GLFWDLL.lib. I accidentally did both.
Additional info at
4.2 Link with the right libraries
in the current GLFW 2.7 Release Notes.
VS C++ 2008
I am just working through a DirectX tutorial.
In the source code had this line:
#pragma comment (lib, "d3d9.lib")
When I compiled everything linked ok.
However, I commented out this line and tried to include the header and library myself under properties, like this:
C/C++ - General
Additional include directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Include"
Linker - General
Additional library directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x64"
Linker - Input: d3d9.lib
However, I got this linker error:
1>main.obj : error LNK2019: unresolved external symbol _Direct3DCreate9#4 referenced in function _initD3D
However, when I just use the pragma I didn't get any linker errors. Only when I try and include them with the properties as above.
What is the real difference in using pragma and including the header/libraries using the properites?
Many thanks,
at first, #pragma comment(lib) is just linker configuration
at second, the SDK should be in path, so dont set additional library directories (you may override it with wrong version), just add d3d9.lib to linker's input.
As far as I know, there is no difference. pragma lib simply says to the linker to look for a specific library by name.
Also, since the path is not specified in the pragma, the linker relies on the current lib paths for your project. Try not add any path to your linker options (by default DX SDK adds paths to any visual studio installed, directly modifying the global visual studio paths. See Tools/Options/Projects and Solutions/VC++ Directories/Show Directories for Library files)
Some things to check:
you are indeed building for x64
your path is really pointing to the DX SDK (it is installed to Program Files(x86) if you are on x64)
verify if there are not other linker warnings