I have a autotools project that I've added a Visual Studio solution and project file for, and everything builds fine until I get to the linking stage. I get this output. An excerpt:
error LNK2005: "public: static bool const std::numeric_limits<unsigned short>::is_signed" already defined in abstract_syntax_graph.obj
Basically, a bunch of multiple definitions for C++ standard library stuff. I'm guessing there is something wrong with my project configuration in Visual Studio but I have no idea what would control whatever feature that is.
I faced similar errors when compiling a project under VS2015 using the /Za flag. Note that this worked fine under VS2013, but wouldn't build until I removed /Za from the VS2015 project.
This doesn't seem like an actual answer to me, I would have thought that there should be no issue disabling language extensions.
Related
My c++ project is using TIBCO's TIBRV library (namely libtibrv.lib, libtibrvcpp.lib), TIBRV x64 version files were compiled by vs10, previously my project was compiled in VS2013 and everything is fine.
Now, when I upgrade my project to VS2017, an LNK2001 error is triggered saying "unresolved external symbol __iob_func referenced ", this is due to Microsoft changed its CRT pathes and libraries (see
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ ) since VS 2015.
However, as there is no maintenance agreement anymore, TIBCO wouldn't provide a x64 TIBRV version compiled in VS2017.
Hence I wonder, is there a way to wrap the TIBRV x64 library files (libtibrv.lib, libtibrvcpp.lib) compiled under VS10, in VS2013, then called from VS2017? How to do that?
So I've recently upgraded VS2013 to VS2015 and I'm still struggling accommodating the code & project's definitions to make it work.
I have dozens of projects in my solution. I also use jsoncpp as an additional lib.
When compiling a single project, I get this error:
3>LINK : fatal error C1047: The object or library file '..\Libs\json_cpp\build\vs71\release\lib_json\json_vc71_libmt.lib' was created with an older compiler than other objects; rebuild old objects and libraries
So I've open the Libs\json_cpp\makefiles\vs71\jsoncpp.sln with VS2015 and rebuild the solution.
that didn't help.
Possible Reason
My projects are all using Platform Toolset Visual Studio 2015 - Windows XP (v140_xp)
while the jsoncpp Platform Toolset is Visual Studio 2013 - Windows XP (v120_xp)
If this is indeed the issue so the obvious solution is to have both solutions compile in the same Platform Toolset Visual Studio 2015 - Windows XP (v140_xp).
Possible Solution
So, I've tried that. and got countless of these warnings:
json_value.obj : warning LNK4006: "public: static int const std::numeric_limits<unsigned short>::digits10" (?digits10#?$numeric_limits#G#std##2HB) already defined in json_writer.obj; second definition ignored
Anybody else suffered from this agonizing process of VS upgrade and can share some insights?
I get this error when I run my sln with Visual studio 2005version 8.0.50727.42 ,.NET framework version 2.0.50727 .
error LNK2001: unresolved external symbol
but I don't get the error while running the same sln through Visual Studio 2005 with .NET framework of little higher version.
I reinstalled the previous version mentioned above.but still having the same linking errors.
Requirement is to build the code with the first version mentioned above.
Please suggest way ot.
Note: the project properties are set the same while building the code with two different version mentioned above.
Try setting the /VERBOSE flag for your linker (Note: Make sure that you set it for the linker). Then look through all included libraries and verify that the one that contains the symbol in question is linked properly.
EDIT: Also note that you will not get a proper warning when linking (or rather failing to link) against 64-bit libraries in a 32-bit project.
Found a lot on this error already, but my case does not get matched with any yet.
I am building a solution (having many projects) in debug mode, and one of them is throwing this error, I am using VS2010 and language is C++, .net version 4.0, earlier this project was compiled in vs2008 and then VS2010, and it was all ok, now I got a new machine which has just VS2010 installed and now facing this error.
Main thing to notice is:
Properties settings:
Project Configuration->General->/CLR is chosen
In C++->General-> No CLR support
I am having these settings since past, it's running all fine in my old machine in VS2010 only in the same debug mode.
What to do?
I am using Visual Studio 2013.
I had similar symptoms for a very simple C program. In the project properties I changed the General / Platform-Toolset setting from "Visual Studio 2010" to "Visual Studio 2013 v120" and that got rid of this error for me.
As the error indicates, precompiled headers are not compatible with /clr-compiled files.
You can disable precompiled headers for the cpp files that are compiled with /clr or for the whole project (C/C++ -> Precompiled Headers -> Precompiled Header : Not Using Precompiled Headers). I'm not sure what the difference is but both seem to work for me.
Doc is not exactly wrong, but I'm betting that's not what's going on here.
Do you by any chance have something like THIS:
#using namespace boost::asio;
...instead of something like THIS?
using namespace boost::asio;
Both "using" and "#using" have valid roles in Visual Studio-- but if you mean the pure C++ language keyword, be sure you are using the former! The latter is indeed used for managed code. See here:
https://msdn.microsoft.com/en-us/library/yab9swk4.aspx
Getting this wrong in Visual Studio 2015 has the following effects:
BUILD OUTPUT:
1>thingy.cpp(3): error C2006: '#using': expected a filename, found 'namespace'
1>thingy.cpp(3): fatal error C1190: managed targeted code requires a '/clr' option
Note that attempting to "satisfy" this in a fit of 4:00 AM frustration by removing the "namespace" keyword and quoting the value will result in only the second error.
(I think that's worth mentioning, because as both Visual Studio and the C++ language specification continue to change, people try all kinds of syntax that they know shouldn't work, and if it suddenly compiles, just assume the spec or the tools have changed in some way they haven't had time to keep up with-- especially if the error messages seem to have something to do with "features" they couldn't care less about, and don't use.)
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:)