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:)
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.)
I have developed a simple (no COM) C++ DLL for VBA (Excel) in VS 2008, which works perfectly on Win 10 and Excel 2016, as well as on Win XP and Excel 2003, both during debug and release. I have developed it following this example.
Now, jumping to the issue, using the same recipe and piece of code I have developed the same DLL, but in VS 2015. The debug and release versions for x64 work perfectly, but when I want to release the DLL for X86, it throws me the following error:
1>defFile.def : error LNK2001: unresolved external symbol "func_name"
Additional info, the project has only 2 files, as in the example:
.cpp
.def
Anyone has an idea how to get over this link issue?
My feeling is that, there might be a setting that I overlooked or skipped!
If you need the code or the settings, I will happily provide them, but they should be as in the example!
Thanks!
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 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.
Background: I'm building a plugin for a large simulation framework. I'm compiling a DLL using Visual Studio C++ 2010.
After much bughunting and googling I believe I have a problem which stems from having multiple versions of CRT linked to my DLL. I'm getting a segfault in tidtable.c (from msvcr100.dll), in the function _CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue(). Reading this thread (there are multiple problems discussed, but towards the end this function is mentioned) is where I got the idea, and if I check the linking part of my project I see msvcr90.dll, ´msvcp100d.dllandmsvcr100d.dll`.
I'm using several external libraries, and I've been able to recompile all but one of them using VS2010. The last one is not open source however (it's a library belonging to the framework), and I guess that is where the dependency would come from. I'm not certain however, how could I check this?
Given that I'm right about where the dependency is coming from, what can I do?
You are linking to the release runtime from Visual Studio 2008 and debug runtime of Visual Studio 2010 ... you shouldn't mix and match release and debug in general. If you need the debug VC9 you'll need to install Visual Studio 2008 (install before 2010 to be safe)
However I'd probably just rebuild all projects and dependencies against VC10. You may be able to get away with installing the redist for VC9 if it's missing from your system for release only.
Edit: Link to Dependency Walker which is invaluable for determining missing or conflicting dependencies.