Qt: windows functions are unresolved external symbols - c++

I'm trying to compile a simple helloworld-like non-Qt C++ application using te WinAPI in QtCreator. Here's the code:
#include <windows.h>
int main()
{
HWND cons = GetConsoleWindow();
SetWindowText(cons, L"I am the console window");
MessageBox(cons, L"Hello world!", L"I am the MessageBox", MB_OK | MB_ICONERROR);
return 0;
}
Looks very simple, but when I've tried to build it, the compilation fails with:
main.obj:-1: error: LNK2019: unresolved external symbol __imp__MessageBoxW#16 referenced in function _main
main.obj:-1: error: LNK2019: unresolved external symbol __imp__SetWindowTextW#8 referenced in function _main
I started to seek, and I found this, but it wasn't helping me at all, because when I had written this:
LIBS += -L"C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Lib"
and even this:
LIBS += -L"C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Lib\\shell32.lib"
in my .pro, these "symbols" still stand unresolved. I ran qmake after each change to the .pro-file contents. So, any ideas?

-L sets the search paths for DLLs, but it doesn't actually link anything. The actual linking is done via -l. Setting the search path for system libraries shouldn't be necessary, but you'll need to link against user32:
win32:LIBS += -luser32

Additional to Frank's answer (which helped me very much, thanks for that!) I would like to add that this is only required vor MSVC, MinGW doesn't seem to need that line. Which was for me the most confusing part, I first thought I had problems with the msvc toolchain.
My inclusion now looks like this to reflect this fact:
msvc: LIBS += -luser32

Related

Missing CoTaskMemFree when building LLVM example on Windows

I'm attempting to essentially follow the llvm Kaleidoscope example.
I'm on Windows. I built llvm from source per the directions on the site. It took quite a long time but it finally built successfully (no errors at least).
Then with my own code I am running this command:
$ clang-cl main.obj llvm/lib/LLVMCore.lib llvm/lib/LLVMSupport.lib /MDd -o build\test.exe
My main.cpp code has this in it:
#include "llvm/ADT/STLExtras.h"
#include "llvm/IR/IRBuilder.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/Verifier.h"
std::unique_ptr<Module> module = llvm::make_unique<Module>("my cool jit", getGlobalContext());
And I'm not getting any parser errors but I am getting an error from the linker that for the life of me I cannot figure out:
LLVMSupport.lib(Path.obj) : error LNK2019: unresolved external symbol
__imp_CoTaskMemFree referenced in function "bool __cdecl
llvm::sys::path::getKnownFolderPath(struct _GUID,class
llvm::SmallVectorImpl<char> &)" (?
getKnownFolderPath#path#sys#llvm##YA_NU_GUID##AEAV?$SmallVectorImpl#D#3##Z)
build\test.exe : fatal error LNK1120: 1 unresolved externals
Which library do I have to link to for this function to be defined? I can see the implementation in the code I built from. Do I need to build llvm in a particular way for this to be exported?
EDIT:
It turns out that I needed to read the clang-cl documentation a little better where it says:
To enable clang-cl to find system headers, libraries, and the linker when run from the command-line, it should be executed inside a Visual Studio Native Tools Command Prompt or a regular Command Prompt where the environment has been set up using e.g. vcvars32.bat.
It turns out that this solves my problem. I was a little confused because clang-cl seems to resolve the sdk include and tool paths automatically, but not the lib paths. I also don't want to use CMD to drive clang so I was using bash where I can't run vcvar32.bat easily. I solved my problem by essentially duplicating what vcvar32.bat is doing to the $PATH, $INCLUDE, $LIB and $LIBPATH environment variables and adding Ole32.Lib as a parameter to clang-cl. It then works like a charm.
You're missing the CoTaskMemFree symbol. A quick look on the Internet suggests you'll need the Ole32 system library on your link line.
I don't have access to a Windows machine to test on, but on my computer, I can run llvm-config --system-libs and it pulls in the all the necessary things. After adding using namespace llvm; and adding a stub main function, I can easily build this example with (on OSX):
c++ `llvm-config --cxxflags` main.cpp `llvm-config --ldflags --system-libs --libs core support`
I often recommend just specifying --libs rather than guessing what you'll need, but your choice.

Using RegOpenKey and RegEnumKey in dynamic QT with MSVC2010

I want to use 2 winapi functions for registry access, as stated.
I have QT 5.3.2 with QT Creator 3.2.0, MSVC2010 build, Windows SDK v7.1 and debugging tools installed.
windows.h is included in my project and both functions are seen, but linker fails with
usb_part.obj:-1: error: LNK2019: unresolved external symbol __imp__RegEnumKeyW#16 referenced in function "bool __cdecl GetUsbName(class QString &)" (?GetUsbName##YA_NAAVQString###Z)
usb_part.obj:-1: error: LNK2019: unresolved external symbol __imp__RegOpenKeyW#12 referenced in function "bool __cdecl GetUsbName(class QString &)" (?GetUsbName##YA_NAAVQString###Z)
I suppose it tries to link those functions dynamically (hense the "__imp"), how can I set it to link against a static .lib file? Or, if that is not possible with dynamically built QT, how do I link those to .dll?
UPD:
Tried these:
LIBS += -ladvapi32
LIBS += AdvAPI32.Lib
LIBS += "c:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\AdvAPI32.Lib"
to no avail
UPD2:
Problem was in QT not recreating makefiles after changes to .pro. After I deleted makefiles, LIBS += -ladvapi32 worked fine. Thought that "Clean project" does that, but it turns out that it doesn't.
You should add to your .pro file
LIBS += -lAdvapi32
or
LIBS += Advapi32.lib
After that run qmake and build again.
[Update] It may be needed to remove generated makefiles manually and recreated them with qmake run again.

Problems linking to FFMPEG library in Visual Studio 2010

I have cross-compiled FFMPEG from Debian using the mingw32 toolchain. The result of the compilation is a set of .a files. When I try to use them in my project I get linker errors, concretely the following ones:
1>RTSPCapture.obj : error LNK2019: unresolved external symbol _avformat_free_context referenced in function ...
1>RTSPCapture.obj : error LNK2019: unresolved external symbol _avio_close referenced in function ...
1>RTSPCapture.obj : error LNK2019: unresolved external symbol _avcodec_close referenced in function ...
(and much more...)
I have already included the header files like this:
extern "C"
{
#include <libavcodec/avcodec.h>
#include <libavformat/avformat.h>
#include <libavformat/avio.h>
}
And I use the .a files like this:
#pragma comment(lib, "libavcodec.a")
#pragma comment(lib, "libavformat.a")
#pragma comment(lib, "libavutil.a")
May I know why I am still getting linker errors? Best regards,
EDIT: I have realized that this is not possible. So, what should I do to use FFMPEG library in my MSVC2010 project taking into account that I can't compile ffmpeg in Windows? it seems to be REALLY difficult...
GCC (the compiler used by MinGW) does not have the #pragma used by VisualC++ to add libraries. You have to manually add the libraries when linking using the -l option:
$ gcc objectfile1.o objectfile2.o -o executable -lavcodec -lavformat -lavutil
Finally I realized that mingw compiles libs could not be linked in VS2010 native applications.

QT moc.exe generating empty files, error involving type_traits

I was trying to build a QT project in QT Creator, but was getting link errors:
minecraftlauncher.obj : error LNK2001: unresolved external symbol "public: virtual struct QMetaObject const * __cdecl Launcher::MinecraftLauncher::metaObject(void)const " (?metaObject#MinecraftLauncher#Launcher##UEBAPEBUQMetaObject##XZ)
minecraftlauncher.obj : error LNK2001: unresolved external symbol "public: virtual void * __cdecl Launcher::MinecraftLauncher::qt_metacast(char const *)" (?qt_metacast#MinecraftLauncher#Launcher##UEAAPEAXPEBD#Z)
minecraftlauncher.obj : error LNK2001: unresolved external symbol "public: virtual int __cdecl Launcher::MinecraftLauncher::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall#MinecraftLauncher#Launcher##UEAAHW4Call#QMetaObject##HPEAPEAX#Z)
debug\Launcher.exe : fatal error LNK1120: 3 unresolved externals
For some reason, moc.exe, the meta-object compiler, was creating empty moc_*.cpp files, with the error message
:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/include/type_trait(0): Note: No relevant classes found. No output generated.
I tried running mocat the command line with the flags it had been run with in QT Creator:
C:\QtSDK\x64\bin\moc.exe -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -I"c:\QtSDK\x64\include\QtCore" -I"c:\QtSDK\x64\include\QtGui" -I"c:\QtSDK\x64\include" -I"c:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include" -I"c:\QtSDK\x64\include\ActiveQt" -I"debug" -I"..\Launcher" -I"." -I"c:\QtSDK\x64\mkspecs\win32-msvc2005" -D_MSC_VER=1400 -DWIN32 ..\Launcher\minecraftlauncher.hpp -o debug\moc_minecraftlauncher.cpp
and it returned the same error. I tried removing several flags one by one, and narrowed it down to -I"c:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include". For some reason, when that directory was on the include path, the "No relevant classes found" error was shown and an empty .cpp file was generated. However, when that directory was not on the include path, moc.exe worked normally.
Due to the error message including :/Program Files (x86)/Microsoft Visual Studio 11.0/VC/include/type_trait(0), I tried renaming the type_traits file in that location so it wouldn't be recognised. When I did that, moc.exe worked normally again (but actual failed as type_traits is included somewhere in the standard library files I have included).
So the error is being caused somewhere in type_traits
From what little I know about type_traits, I believe it has something to do with getting compile type information about an object. But I have no idea why it is causing the meta-object compiler to err. Why is it doing this? What is moc doing with type_traits, why is it and what is failing?
I will be very grateful for any insight anyone can provide, as this has been very puzzling for me.
The minecraftlauncher.hpp file:
#ifndef MINECRAFTLAUNCHER_HPP
#define MINECRAFTLAUNCHER_HPP
#include <QMainWindow>
namespace Launcher {
class MinecraftLauncher : public QMainWindow
{
Q_OBJECT
public:
explicit MinecraftLauncher(QWidget *parent = 0);
~MinecraftLauncher();
private:
};
}
#endif // MINECRAFTLAUNCHER_HPP
This is most likely a moc bug exposed by C++11 headers. I bet you didn't recompile Qt from the sources, as that would similarly fail.
Visual Studio 11 is not supported by Qt. It's not even in tier2 support. The workaround is to use MSVC 2010 until the bug is fixed, or for you to fix moc and submit a patch :)
I was getting a similar error but with Visual Studio 12 and Qt was direct from Qt. So Kuba Ober's answer did not work.
:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/include/type_trait(0): Note: No relevant classes found. No output generated.
What did work was to surround references to Qt headers with (not) Q_MOC_RUN as shown below.
Using the top portion of Daniel Mulcahy's code...
#ifndef MINECRAFTLAUNCHER_HPP
#define MINECRAFTLAUNCHER_HPP
#ifndef Q_MOC_RUN
# include <QMainWindow>
#endif //Q_MOC_RUN
namespace Launcher {
class MinecraftLauncher : public QMainWindow
{
Q_OBJECT
...

How to link against a static library which uses static libraries itself using scons and Visual C++?

My SConstruct file looks something like this:
jnglLibs = Split("freetype png ogg vorbisfile") # left out a few
env.Library(target="jngl", source=source_files, LIBS=jnglLibs)
env.Program("test.cpp", LIBS=Split("jngl") + jnglLibs)
The static library links fine but the program fails with unresolved external symbols from the libraries in jnglLibs.
lib /nologo /OUT:jngl.lib finally.obj freetype.obj main.obj opengl.obj sprite.ob
j tess.obj texture.obj window.obj windowptr.obj callbacks.obj ConvertUTF.obj aud
io.obj win32\message.obj win32\time.obj win32\window.obj
cl /Fotest.obj /c test.cpp /TP /nologo /EHsc /MD -O2 -DNDEBUG /I.
test.cpp
link /OUT:test.exe /LIBPATH:. /LIBPATH:lib jngl.lib freetype.lib png.lib opengl3
2.lib glu32.lib user32.lib shell32.lib gdi32.lib z.lib jpeg.lib dl.lib openal32.
lib alut.lib ogg.lib vorbisfile.lib test.obj
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
jngl.lib(freetype.obj) : error LNK2019: unresolved external symbol FT_Done_FreeT
ype referenced in function "public: __cdecl jngl::Font::~Font(void)" (??1Font#jn
gl##QEAA#XZ)
... and so on
Why doesn't it find the symbol FT_Done_FreeType which is in freetype.lib? It works perfectly with GCC.
There are a lot of quirks with static linking on Windows.. I've had one or two similar problems to this but mostly my problem was once the 'static' libs were compiled they still depended on the .dll's being there. Anyway, I've been feeling your pain for a while now but got through it for my purposes... here's one page that really helped me.
http://xmlsoft.org/XSLT/tutorial2/libxslt_pipes.html#windows-build
It doesn't have to do with those particular libraries you listed but it might give you some clues. One thing is figuring out which C-runtime library each of those .libs (or '_a.libs,' which you might want to look into) were compiled against and make sure they are all the same when you statically link. So since you're using /MD, make sure all those libs were also compiled with /MD and not /MT. That COULD be a reason it isn't finding that freetype symbol, but it's just one guess. Good luck!