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.
Related
I've successfully compiled my main.cpp with clang, specifying additional include path via the command line options as follows: clang++ -I ./Dependencies/GLFW/include/ -S .\main.cpp.
However, when I try to link it by specifying the additional link library by the following command: clang++ -L ./Dependencies/GLFW/lib/glfw3.lib .\main.s it gives me a linker error main-8b7c4e.o : error LNK2019: unresolved external symbol glfwInit referenced in function main.
Any suggestions on what might be wrong? I'm sure that the relative path specified is correct, since the compile command gave me no issues.
main.cpp
#include <iostream>
#include <GLFW/glfw3.h>
int main() {
glfwInit();
std::cout << "Hello world" << std::endl;
return 0;
}
-L is for specifying folders to search for libraries in. The compiler ignores directories that don't exist.
Your command line should be:
clang++ ./Dependencies/GLFW/lib/glfw3.lib .\main.s
Please find below link for more detail about glfw header inclusion.
https://www.glfw.org/docs/latest/build_guide.html
Given this library:
lib1.h:
#pragma once
#include <windows.h>
void foo();
lib1.cpp
#include "lib1.h"
void foo() {
MessageBox(NULL, "XXX", "YYY1", MB_OK);
}
Created in the command line with the next commands:
cl /c lib1.cpp
lib lib1.obj
And then this little test:
#pragma comment(lib, "lib1")
#include "lib1.h"
void start() {
foo();
}
I've tried to run it on a windows vs2015 project setting:
/NODEFAULTLIB
entry:start
optimization disabled (/Od)
(security check disabled) /GS-
But I'm facing a linker error such as:
main.obj : error LNK2019: unresolved external symbol "void __cdecl foo(void)" (?foo##YAXXZ) referenced in function "void __cdecl start(void)" (?start##YAXXZ)
I've tried changing the pragma comment to #pragma comment(lib, "lib1.lib"), #pragma comment(lib, ".\\lib1.lib"), #pragma comment(lib, "./lib1.lib") and none of them worked.
I've also tried to include in the linker additional paths the path of lib1.lib and then using either #pragma comment(lib, "lib1.lib") or ``#pragma comment(lib, "lib1.lib")`, no luck.
In fact, the funny thing is, when turning on the /VERBOSE in the linker I don't see any linker's attempt to use the #pragma directive. Of course, If i added lib1.cpp or lib1.lib to the project it'd work but I'm trying to figure out how to use the pragma directive... So, anyone could explain what's going on here and how to solve this issue?
Don't use /NODEFAULTLIB, it basically instructs the linker to ignore the lib #pragma. Explanation from here for instance:
When you use #pragma comment(linker) or #pragma comment(lib) you get a
special entry in the object file (it's a special COFF section usually
named ".drectve" with the directive bit set). Once the linker sees
this entry it treats it as if the switch was given on the linker
command line.
So:
t.cpp:
#pragma comment(lib,"advapi32.lib")
...
cl t.cpp
is equivalent to
t.cpp:
...
cl t.cpp /link /DEFAULTLIB:advapi32.lib
and when you add /NODEFAULTLIB to that last comment it will ignore whatever is specified as /DEFAULTLIB
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.
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
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
...