I am building a Windows OpenGL application with bullet physics support.
My development environment setup is :
OS : Windows 7 SP1 64 bit
IDE ; Visual Studio 2010 SP1
BulletPhysics - bullet-2.82-r2704
My application has two configurations i.e. Win32 and x64.
Here's my step to build the Windows application :
First I execute the vs2010.bat file in "bullet-2.82-r2704\build".
I add project files from vs2010 folder created by step 1 into my visual studio solution.
Add project dependencies for BulletDynamics, BulletCollision and LinearMath
Add References for all the thee bullet libraries.
Now when I build my solution for both the configurations (i.e Batch Build for Win32 and x64), everything builds properly except for :
x64 Release - with errors like :
BulletCollision_vs2010_x64_debug.lib(btDefaultCollisionConfiguration.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in stdafx.obj
Win32 Release - with errors like :
Win32_Window.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall btConvexInternalShape ...
Win32 Debug - with errors like :
Win32_Window.obj : error LNK2019: unresolved external symbol "public: __thiscall btRigidBody
Final message - Build: 13 succeeded, 3 failed
I am following this help to build my Visual Studio project :
http://bulletphysics.org/mediawiki-1.5.8/index.php/Creating_a_project_from_scratch#Create_a_new_Visual_Studio_project
Note: If I use CMAKE to build VisualStudio solutions for BulletPhysics and then link those separately to my windows application for each CPU architecture then it builds properly (i.e. Build for Win32 and x64 separately).
Is there any way I can make that work with just one Visual Studio solution ?
In x64 Release you are trying to link a static library compiled in debug mode (BulletCollision_vs2010_x64_debug.lib) with object files from your app compiled in release mode (stdafx.obj specifically). Compiler options (_ITERATOR_DEBUG_LEVEL) of your object files and compiler options of a lib don't match (values 0 for release and 2 for debug respectively). That's why linking fails. And in Win32 Debug and Win32 Release cases it looks like you don't link libs at all.
I think that project references went wrong way.
In my opinion while "Project references" is good for C# style of modules, in native development it is more like unnecessary complication of things. Just add plain old libs to linker input explicitly, like this:
..\..\lib\BulletDynamics_vs2010_x64_debug.lib
..\..\lib\BulletCollision_vs2010_x64_debug.lib
..\..\lib\LinearMath_vs2010_x64_debug.lib
Change "debug" and "x64" parts accordingly for each configuration. I think it is more reliable.
Add BulletDynamics, BulletCollision and LinearMath to "Project dependencies" for your app project. That will guarantee that bullet will be built before your app. Check "Build order" tab to make sure that builds go in right order.
Double check that compiler options are the same for each module.
In <Build->Configuration manager> for all "Solution configurations" and all "Solution platforms" (dropdowns above) check that project configurations and platforms are right. (i.e. you don't have projects that use debug when you switch solution to release and vice versa)
Still fails? Take a look at sample Bullet applications, like "App_HelloWorld". Compare it's options to your app's options, and you will surely find a source of error.
Probably, you could make it other way around: add your app project to Bullet's solution (remove unneeded stuff), to see if it works.
Related
I have an MFC C++ project, which builds and runs just fine with Visual Studio 2022 on Windows 10. The project doesn't use Qt at all. After I installed Qt 6.2.1 with vcpkg, project stopped building with this linker error:
1>Qt6EntryPoint.lib(qtentrypoint_win.cpp.obj) : error LNK2019: unresolved external symbol main referenced in function WinMain
Again, there is no usage of Qt6 in my project. Going to project's Configuration Properties and disabling Use Vcpkg makes it build again. What is going on here and how to fix it without disabling vcpkg?
I created a new C++ MFC App with VS project wizard and default settings. It builds fine with vcpkg enabled.
The only reasonable explanation I can offer is that many generations ago, older VS, older Windows, my project was using a few classes from Qt4 core for a while, which caused problems, so that functionality was removed. I continued to develop it on Windows without Qt installed. Is it possible that some reference to Qt is still lurking around? How to find it? I checked settings several times and couldn't find any.
I looked at the order of library search (/VERBOSE:Lib) and with vcpkg -> Use Autolink enabled, vcpkg folders are searched first. Is there a way to make the linker search system folders first?
Here is what's happening:
1> Searching C:\src\vcpkg\installed\\x64-windows\lib\Qt6EntryPoint.lib:
1> Found WinMain
1> Referenced in msvcrt.lib(exe_winmain.obj)
1> Loaded Qt6EntryPoint.lib(qtentrypoint_win.cpp.obj)
Excluding Qt6EntryPoint.lib with /NODEFAULTLIB:"Qt6EntryPoint.lib" has no effect. Is there another way to exclude it?
This means you should open up an issue in vcpkg.
Qt6EntryPoint.lib needs to be moved into the /manual-link subfolder.
(I really hate the lazy MSBuild autolink/link everything feature of vcpkg.)
We're facing a strange issue and I've run out of troubleshooting ideas. The issue is that on some machines, which are running Visual Studio 2017 Community, we get reports that our project (which is CMake based) gets linker errors like this:
17>------ Build started: Project: ndt, Configuration: RelWithDebInfo x64 ------
17> Creating Library E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.lib and object E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.exp
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol edKJPOs664VT referenced in function "void __cdecl CheckLibraryLicenses(struct NodeInput*,...)
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol zzPIPSGJWa referenced in function main
...
17>E:\NDT_3_0\19_sep18\qualnet\bin\exata_so.exe : fatal error LNK1120: 17 unresolved externals
(Apologies if there are typos: for some reason they sent us a screenshot of the text instead of just a copy-and-paste of the text, so I'm transcribing. However, the parts I'm leaving out contain no mention of errors trying to open lmgr.lib which defines these symbols.)
The strange thing is, we can't reproduce these errors here when we do a fresh clone of the same Bitbucket repository they're using and follow the same build instructions. About the only difference I can tell is that our machines are running Visual Studio 2017 Professional. (Though I'm certainly not sure if this is actually the cause of the behavior differences.)
So far, what we've checked:
The library that contains the unresolved external symbols passes sha1sum checks so their Git client isn't corrupting the library binary file lmgr.lib - and same for the ndt-main-windows-x64-vc14.obj file.
The generated ndt.vcxproj project contains (the correct path to) lmgr.lib in the "Linker -> Input -> Additional Dependencies" property, as expected.
The lmgr.lib file does define the mentioned symbols (verified by Cygwin binutils nm).
On their machines, they get essentially the same linker errors whether using the Visual Studio 15 2017 Win64 generator and building from the IDE, or using the NMake Makefiles generator and building from a command prompt. Both configurations work fine on our machines.
I was wondering if somebody out there might have any ideas on why some machines might be failing to find the symbols in lmgr.lib whereas our machines have no problems completing the link stage.
(Possibly relevant: lmgr.lib contains the FlexNet Publisher licensing libraries where the symbols in both lmgr.lib and ndt-main-windows-x64-vc14.obj have been obfuscated by Flexera's lmstrip tool.)
It turned out that when we asked them to upgrade their Visual Studio 2017 Community installation to the latest service pack release, then after that the linker errors disappeared.
I want to rebuild Crypto++ via MSVC 2013 so when I am using the library to be able to build my project with /MD or /MDd, NOT /MT or /MTd, because I am using QT 5.5.1 with MSVC2013 32bit compiler and it seems if I want to make GUI interface - it is using /MD or /MDd! In this article in section Static Versus Dynamic Linking is mentioned the necessity for rebuilding (not building) and how you can see from my other question I did it, but it is only working for debug mode. For Release mode the errors from 117 go to 53, but again the same old error occures:
cryptlib.lib(cryptlib.obj):-1: error: LNK2038: mismatch detected for
'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value
'MD_DynamicRelease' in main.obj
I am doing just what I mentioned here
I want to rebuild Crypto++ via MSVC 2013...
OK, so the pain points here are the Microsoft changes to MSBuild at 2010. To make matters worse, VCUpgrade does a rather poor job of up-converting projects.
To help users with the upgrade process, Crypto++ provides a file called vs2010.zip. The archive contains the pre-converted solution file, project files and filters for Visual Studio 2010 and above. The files were released in October 2015 with a 5.6.3 Release Candidate.
The upgraded solution files are mostly successful. They build 20 of 24 configurations properly from the IDE. 4 of them fail on the first attempt; but the process recovers on the second attempt and builds all 24. We know its a dependency/ordering issue, but we don't know how to solve it. There's an open question on Stack Overflow at How to control order of Batch Build → Build All.
There is now a page on the subject of Visual Studio 2010 and VCUpgrade. See Visual Studio on the Crypto++ wiki.
In this article ...
I wrote that article years ago. You are on the right track.
I did it, but it is only working for debug mode. For Release mode the errors from 117 go to 53, but again the same old error occures:
cryptlib.lib(cryptlib.obj):-1: error: LNK2038: mismatch detected for 'RuntimeLibrary':
value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in main.obj
We added a ZIP file for you. The ZIP is a pre-converted Visual Studio 2010 solution and project files that utilizes dynamic runtime linking (/MD and /MDd). (Its not really just you since a lot of folks have asked about it over the years).
The solution to your problems are:
download vs2010-dynamic.zip from the Crypto++ wiki
unzip over top of the exiting Crypto++ distribution files.
I am using cryptopp from source with /MD, built on vs2013 using the latest cryptopp version (5.6.2). You want to be up to date on encryption or security software, plus they may have fixed platform build issues.
The issues you cite sound like intermediate files from building a project with /MT set, even if it was later changed to /MD (although it is dangerously easy to forget to change the drop-down to "all configurations", and change just the debug settings in one project).
First clean solution, then make sure you change every project to /MD in [bold]all configurations[bold], and clean solution again. Now search for and delete any debug or release folders and .obj .lib .dll files, because I don't trust "clean solution". It can only get files it intends to build under the current settings, but the linker might find more in the link search (/verbose:lib).
Then rebuild all.
I ran into this problem recently (few days ago everything was working fine): Visual Studio 2012 started to refuse to build native WP8 projects.
Today, I created new solution from template 'Windows Phone Direct3D App (Native Only)' to check if my newly created DLLs will be properly supported on WP. I tried to compile this project, first without any changes or additional references - pure code generated by VS. However, it failed with given error.
I know very well what does it mean and what could be the possible reason, but I can't understand, hovewer, where does it come from in this case.
Weird thing: this only happens in 'Win32' configuration, ARM compiles fine:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug ARM ------
.......
Build Summary
-------------
00:11.742 - Success - Debug ARM - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
but Win32 does not:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug Win32 ------
.......
1>LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
Build Summary
-------------
00:09.725 - Failed - Debug Win32 - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
My standard (native C++/Win32) projects also work as expected (in both Win32 and x64 platform targets).
Project configuration: (in both platforms)
Linker::Input:
d3d11.lib;%(AdditionalDependencies)
Linker::Ignore:
ole32.lib;%(IgnoreSpecificDefaultLibraries)
VC++ Directories:
Microsoft.ARM.Cpp.User:
$(WP80ToolSetPath)lib\arm;$(WindowsSDK_LibraryPath_ARM);
Microsoft.Win32.Cpp.User:
$(VCInstallDir)lib;$(VCInstallDir)atlmfc\lib;$(WP80ToolSetPath)lib\x86;$(WindowsSDK_LibraryPath_x86)
Any ideas what else could be wrong or configured incorrectly? I'm running out of ideas, I have never seen something like this before.
By the way, I have noticed one more change: when I was trying to compile WP8 projects in ARM configurtion before, there was always an error, saying "building ARM application on desktop is not supported" (or something like that). Now ARM compiles with no problem. Is it normal?
Finally, I have found the reason of my problems: as I suspected, internal Visual Studio configuration has been broken.
I did all standard steps, that can be performed in case of LNK1104, however:
- kernel32.lib was in valid location
- all include and library directories was correct
- standard *.props files were attached to each project
However, the cause was lying elsewhere.
All paths are defined using standard macros. One of them is $(WindowsSDK80Path), which is used to build include/library paths. On my system, this macro was defined as
C:\Program Files (x86)\Windows Phone Kits\8.0
instead of
C:\Program Files (x86)\Windows Kits\8.0
And that's it. I do not know, when or how, this problem arosed. Visual Studio repair via orginal installer was sufficient method to fix everything. All projects compile now without any problems.
I've created an OpenGL (GLEW) project in VS2012 and it is working perfectly. Now I've moved the project to VS2013. I've created a new project and set the project's environment the same as I did in VS2012:
Character Set:--------------Use Multi-Byte Character Set
Include Directories:--------C:\Foo\glew-1.9.0\include
Library Directories:--------C:\Foo\glew-1.9.0\lib
Additional Dependences:-opengl32.lib; glu32.lib; glew32.lib
Runtime Libary:-------------Multi-Threaded Debug (/MTd)
All code is exactly the same as before, but when I run the program, I get this error:
Error 1 error LNK2019: unresolved external symbol _main referenced in
function ___tmainCRTStartup c:\FooBar\...\Projects\OpenGL\OpenGL\LIBCMTD.lib(crt0.obj)
OpenGL
I can't see why this same project with the same settings and code doesn't work when it is an exact duplicate.
Hi #SpicyWeenie LIBCMTD is the debug version of the static multi-threaded C runtime library, and according to Microsofts licensing you cannot use than in the release version of code, I would check you are compiling in debug mode:
in debug mode use /MTd as the runtime library
in release mode use /MT as the runtime library
This will hopefully help, if not, then clean your project before building, and if that does not help either, apply liberally with swearing before creating a new project and ensuring it is a Windows Console Application and not a Windows Application (the last one has been the most common cause of the exact error you are describing for me, and happens mostly to me when moving between versions of Visual Studio (2008 to 2010 or 2010 to 2012)
Sincerely hope this helps, but if it doesnt let me know and maybe I can figure out whats wrong:)