I have compiled QT5.6.2 myself with Visual Studio 2015 to compile some other software (Telegram desktop; build instructions are here https://github.com/telegramdesktop/tdesktop/blob/dev/docs/building-msvc.md#setup-gypninja-and-generate-vs-solution ).
Curiously, it seems necessary to state that I know what an unresolved external symbol is - but that I still cannot solve my issue, especially since it lies within a library that is not custom-made by me: QT
Now, when I try to compile Telegram with Visual Studio 2015 which depends on QT5.6.2, I get a weird unresolved symbol:
1>qwebpd.lib(upsampling.obj) : error LNK2019: unresolved external symbol
"_WebPInitUpsamplersSSE2" in Funktion
"_WebPInitUpsamplers".
I could not find anything on this function or in which library it might/should be defined.
It seems that the QT Webkit is built with Chromium and that during QT's compilation I have somehow activated some kind of SSE2 extension which, however, does not seem to be available now in Visual Studio 2015. I have also tried in "Project Settings -> C/C++ -> Code Generation" to explicitly activate SSE2 but without help. I have no clue where this function should actually be defined.
I know in general what an unresolved external symbol is, but I do not know how to resolve this error in my specific case with QT.
Related
The compile all goes well. However, when it goes to the link stage, error comes out:
error LNK2001: unresolved external symbol _ptrc_glClear
There're also many other errors with the same link error, including _ptr_glViewport, _ptr_glDrawArrays......
I'm searched in stackoverflow, and find many questions about the link problem of opengl32.lib. I followed their advice, but still it doesn't work.
I also notice that, the problems occurred in others' question(error LNK2019: unresolved external symbol), appear to be somewhat different: what they failed to link is with the prefix "imp", while mine is "ptr".
I wonder, is the problem of the "_ptrc_xxxxx" thing also comes with the opengl32.lib, or did I miss some other libs to link?
Are you using any kind of OpenGL loader library (GLee, GLEW, glLoadGen)? Prefixed OpenGL symbols are usually imposed on your source code by including such a loaders header (which uses some preprocessor magic to turn all OpenGL symbols in your code into symbols referring to the loader). If then your program fails to link with that very loader you'll get these unresolved symbol linker errors.
I'm writing a right click context menu extension dll for Windows to support functionality in another program.
It's building fine targeting Win32, but when I try to build for x64, I get this
error LNK2001: unresolved external symbol _vswprintf
I am not actually calling it anywhere in my code, so even if it is undefined, that shouldn't be a problem. (I am including stdio.h, stdarg.h, and wchar.h though, so it should be defined.)
I have a problem writing wrapper program to use vendor's library in .Net client program(C#).
What the vendor provided are C++ header file and MFC static library file(.lib) built on both release and debug.
The problem is, when I build wrapper program, Visual Studio 2012 spits LNK error out like this:
error LNK2001: unresolved external symbol ___argc nafxcwd.lib(appcore.obj)
error LNK2001: unresolved external symbol ___argv nafxcwd.lib(appcore.obj)
I set up build property with option /clr,
set runtime library as Multi-threaded debug DLL (/MDd),
set using MFC as MFC in shared DLL,
ignored libraries(nafxcwd.lib;msvcrtd.lib;msvcmrtd.lib;libc.lib;libcmt.lib;msvcrt.lib;libcd.lib;libcmtd.lib, see this),
added dependencies(nafxcwd.lib;msvcrtd.lib;msvcmrtd.lib;(vendor's library), for CRT, MFC library order).
What I missed?
I don't know I described enough. If something is ambiguous, please ask to me.
Thanks in advance!
ps. I'm very new to C++(even Visual Studio..). I'm more familiar with Java.
I'm trying to get around these link errors:
error LNK2001: unresolved external symbol "__declspec(dllimport) public void __thiscall std::basic_ostream(char,struc std::char_traits<char>>::_0sfx(void)"
I used Visual Studio C++ 2010, and tried with Visual Studio C++ 6.0, but still the same errors show up.
The object file is found, so I am suspecting that it cannot find the implementation of the std library? I've tried /nodefaultlib option on a few libraries (libc.lib, libcmt.lib, msvcrt.lib, etc) but did not improve the situation at all.
Could someone explain why the error occurs and where I should look ?
Tried the solutions suggested in other similar questions but they either are not applicable or do not resolve the problem.
Thanks
You should remove /nodefaultlib option.
This problem could arise if some of your libraries are linked static while other dynamically.
Basically if you have both codes compiled with the static version of CRT (that's compiler switch /MT and /MTd) and dynamic version of CRT (switch /MD, /MDd).
You can see what your project is using in Project Properies - c++ - Code Generaion - Runtime Library)
Make sure all your libraries are compiled with the same switch as you project.
I have a library which is compiled in VS 2005 and I am trying to link it with one of the old VC 6 workspace, while linking I am getting following errors.
error LNK2001: unresolved external symbol _sprintf_s
error LNK2001: unresolved external symbol _strncpy_s
error LNK2001: unresolved external symbol _strcpy_s
error LNK2001: unresolved external symbol _strcat_s
error LNK2001: unresolved external symbol __time64
unresolved external symbol __alloca_probe_16
unresolved external symbol _main
fatal error LNK1120: 7 unresolved externals
Error executing link.exe.
Please help me in getting away with this error.
_strcpy_s is not defined in the VC6 libraries, it was added in VS2005 (or maybe VS2002/2003 ?). I don't think there's a way around it.
AFAIK, it's not usual to use a library from an earlier version of the compiler with an older version of the compiler.
I assume the above is a result of you statically linking the executable?
The _s functions are "safe" functions that Microsoft added to the runtime library to make it harder to write code with buffer overflows. They were added after VC6 (either in VS.NET or VS2003) and the functions are not present in the VC6 runtime libraries, so that is why your link is failing. The only two ways to get around this are either to build the whole set of binaries with VS2005 or with VC6. The latter is probably not a good idea as it would require you reworking the library to use the standard C functions instead.
It is generally not a good idea to mix compiler versions in static libraries and executables as the runtime libraries do change and you're left with problems like these.
You could turn your library into a DLL, but that's opening another can of worms...