I'm making a C++ program and I want to use FFmpeg pre-built for x64, which is a C-compiled library.
I'm using this code in order to include its header:
extern "C" {
#include "libavcodec/avcodec.h"
#include "libavformat/avformat.h"
#pragma comment (lib,"G:/Documents/ffmpeg/lib/avcodec.lib")
#pragma comment (lib,"G:/Documents/ffmpeg/lib/avformat.lib")
}
I'm then calling the symbols like I would do for a normal function, for example with av_interleaved_write_frame(out->formatContext, &packet);
However, when I try to compile it with Visual Studio 2015's built-in C++ compiler, I get a lot of error like
Error LNK2019 unresolved external symbol _av_write_trailer referenced in function "void __cdecl closeArenaVideo(struct VideoOutput *)" (?closeArenaVideo##YAXPAUVideoOutput###Z) Sparta2 c:\Users\Théo\documents\visual studio 2015\Projects\Sparta2\Sparta2\video.obj
for basically any of the symbols I'm refering to.
I tried to import everything in Visual Studio, to compile with command-line, to manually put FFmpeg's libraries in the default libraries path, without success.
Thank you in advance!
A typical problem which is hard to understand from quoted linker errors is the problem of referencing wrong .lib files, esp Win32 platform libraries in x64 build and vice versa. The names might be correct, but the set is wrong and then linker takes the #pragma references but ignores the content.
You should make sure that your build platform matches the bitness of referenced library files. This answer has minimalistic project which does build well and you can compare code/references to what you use, and it also mentions bitness problem as well in the very bottom and comments to the answer.
Related
I'm currently attempting to compile a VST3 plugin (or any C++ code, for that matter) for the first time, mainly just following Steinberg's own tutorial for all things except the actual sound processing.
Attempting to compile throws an "unresolved external symbol" error:
Error LNK2019 unresolved external symbol "public: __cdecl VSTGUI::VST3Editor::VST3Editor(class Steinberg::Vst::EditController *,char const *,char const *)" (??0VST3Editor#VSTGUI##QEAA#PEAVEditController#Vst#Steinberg##PEBD1#Z) referenced in function "public: virtual class Steinberg::IPlugView * __cdecl Itisdud::Split_TimesController::createView(char const *)" (?createView#Split_TimesController#Itisdud##UEAAPEAVIPlugView#Steinberg##PEBD#Z) Split_Times D:\programme\VST3Dev\Split_times\Split_Times\build\split_timescontroller.obj 1
The function that causes this, createView, is still the default it is when created by the Project Generator:
IPlugView* PLUGIN_API Split_TimesController::createView (FIDString name)
{
// Here the Host wants to open your editor (if you have one)
if (FIDStringsEqual (name, Vst::ViewType::kEditor))
{
// create your editor here and return a IPlugView ptr of it
auto* view = new VSTGUI::VST3Editor (this, "view", "split_timeseditor.uidesc");
return view;
}
return nullptr;
}
Copying the createView function from the again and adelay samples didn't work either.
As the Project generator only includes vstgui4/vstgui/plugin-bindings/vst3editor.h and not the vst3editor.cpp file, I tried including that as well (As I've read that not having the actual implementation there might be the cause of the issue), however that didn't fix the issue but made a lot of other errors happen upon compiling.
I also tried to follow this, including the cpp files noted there and changing the createView function to what is written there, however this also only led to there being a bit more than 300 errors upon compiling.
Copying the includes from the again sample didn't work either.
What would I need to include for this to work?
Those are the linker errors as you didn't instruct the linker where to find the required library files whose functions you are using.
Remember that compilation is a 2-step process that involves compilation and linking so it is best to separate them.
Lets assume you are using Visual Studio on Windows, and lets assume your VST SDK is installed on
C:\VST3SDK.
The first thing you should do is fire-up Visual Studio and select File->Open->CMake and go locate the CMake.txt file here
C:\VST3SDK\VST3_SDK.
After this file is loaded you will find on Visual Studio Solution Explorer a list of ready-made projects that come with the VST SDK loaded.
You will find that one of these projects is called Libraries and that is THE first action you have to do.
Now you have to build the correct library depending on whether you want to make 32-bits or 64-bits VSTs and you should set the configuration of the Libraries project accordingly.
You will build these libraries and if you hadn't changes any setting the libraries will be found at
C:\VST3SDK\VST3_SDK\out\build\x64-Debug\lib
or
C:\VST3SDK\VST3_SDK\out\build\x64-Release\lib
the necessary libraries being:
base.lib
pluginterfaces.lib
sdk.lib
sdk_common.lib
sdk_hosting.lib
vstgui.lib
vstgui_standalone.lib
vstgui.support.lib
vstgui_uidescription.lib
The above step ensures that you now have the necessary library files your VSTs will depend on.
Now assuming you have a VST sample project, lets say that you got from Git-hub and that it were written and setup correctly to run on Visual Studio, i.e. it came with a
myVST.vcxproj file.
Then you could paste the following pragmas on a prominent VST file such as the factory.cpp
#pragma comment(lib, "base.lib")
#pragma comment(lib, "pluginterfaces.lib")
#pragma comment(lib, "sdk.lib")
#pragma comment(lib, "sdk_common.lib")
#pragma comment(lib, "sdk_hosting.lib")
#pragma comment(lib, "vstgui.lib")
#pragma comment(lib, "vstgui_standalone.lib")
#pragma comment(lib, "vstgui_support.lib")
#pragma comment(lib,
"vstgui_uidescription.lib")
(Had to abbreviate due to confusing formatting requirements of this site but replace like "vstgui.lib" with a fully qualified path like
"C:/VST3SDK/VST3_SDK/out/build/x64-Debug/lib/vstgui.lib"
Now if your project properties
C/C++ _> General _> Additional Include Directories has correct entries that will tell the compiler the paths it will find ALL the #include files, then you will find that if you right click on any compilable file (c, cpp, rc ...) and select Compile then the file should successfully compile into an object file without any Compiler errors otherwise it is an indication that the compiler cannot find the required header
files.
But the problem you face are the linker problems, the linker can not find the required libraries of functions you have used in your project and the solution is just pasting the pragmas above.
Under Visual Studio (2017) I am trying to script a C++ program with Lua 5.3 but the linker does not find three function names referenced in my C++ source file:
unresolved external symbol _lua_close
unresolved external symbol _lua_createtable
unresolved external symbol _luaL_newstate
I took the C++ source from the Lua website.
I downloaded the Lua 5.3 dynamic library which does not come with an import library so I created the import library with the MSVC tools like so:
dumpbin /exports E:\Documents\Programmation\Lua5.3\lua53.dll
From the output of dumpbin, I copied the 146 names in a new file "mylua53lib.def" and ran lib to generate the .lib file like so:
lib /def:E:\Documents\Programmation\Lua5.3\mylua53lib.def /OUT:E:\Documents\Programmation\Lua5.3\mylua53lib.lib /machine:x86
The three function names that the linker does not find are indeed not appearing in the output of the dumpbin command.
A binary distribution of Lua intented for dynamic linking on Windows should come with two binary files:
a DLL file with the actual Lua code
a library file with the method stubs delegating to the DLL
Sometimes the library file will come with an .a extension, which is more common on Linux (as opposed to .lib on Windows). If it's a Windows build, though, you can simply pass that file as a linker dependency and it will work just fine. This question deals with differences between the two conventions.
As a side note, in order to make it work, if you create a C++ project in Visual Studio, and add a Source.cpp as it suggests by default, you'll still get unresolved externals. This is due to the fact that while the C sources compile as C++ code just fine, the linker will expect mangled names for the definitions of the C functions used. This can be prevented by either compiling the file as C code, or, preferrably, by telling it that the names from Lua headers should be unmangled in the linked library using extern "C":
extern "C" {
#include <lua.h>
#include <lualib.h>
#include <lauxlib.h>
#include <stdlib.h>
#include <stdio.h>
}
I've got an NIUSB8452 DAQ, with which the vendor thoughtfully provided ni845x.lib and ni845x.h so I could use C instead of LabView to do my data reading. However, I'm having some problems with getting the lib working in VisualStudio 2015. The first point of alarm is probably that their documentation says it is compatible with VS6, but I've seen other people on here successfully use libraries for VS6 on VS15, so, I hope I can also be so beautiful.
The problem that I am having right now is that on a build, I'm getting linker errors that read something like
unresolved external symbol #ni845xStatusToString#12 referenced in function (function name follows)
While googling around, I found this question which mentioned dumpbin /exports. To check that I wasn't running into a 32/64 bit error like the poster described (since I wasn't really sure how to diagnose this, it seemed as good a place to start as any), I ran dumpbin /exports on the external lib. I got a pile of public symbols, including
FF06 __imp__ni845xStatusToString#12
FF06 _ni845xStatusToString#12
I'm definitely not seeing #ni845xStatusToString#12, which is what VisualStudio is complaining about being unresolved.
What's the difference between #ni845xStatusToString#12 and _ni845xStatusToString12? What does the presence of the latter and the absence of the former indicate that I am doing wrong with this import?
Notes
The lib and header have been included in the file as described in this question, with the exception that I gave a full path to the lib for #4, which I think implies you only need the filename.
I'm using extern "C" { #include ni845x.h } in my cpp file, although ni845x.h does have the #ifdef __cplusplus boilerplate in there.
I am trying to statically link this library into my VS C++ project.First I compiled the source as a static lib.Linked it via VS Project properties.The .exe project works fine.Then I read this MS manual on how to compile the static lib into the executable and following the steps outlined there now if I am running the executable I am getting these errors:
Error 3 error LNK2019: unresolved external symbol __imp__glBlendFunc#8
referenced in function _text_buffer_render E:\Documents\visual studio
2012\Projects\XXXXEngine\FreeTypeTest\text-buffer.obj
Error 4 error LNK2019: unresolved external symbol __imp__glBindTexture#8
referenced in function _text_buffer_render E:\Documents\visual studio
2012\Projects\XXXXEngine\FreeTypeTest\text-buffer.obj
To me it seems like GLEW.lib errors.Does it mean I have to link also glew.lib statically as the freetype GL depends on it ?
Also, can I just use the lib with the executable without adding it to references, or it won't work in release build?I am asking it as I am quite confused with how the static linking should be done.I mean,now the executable works without adding the library to the project reference.Then why can't it be used just like this?
To me it seems like GLEW.lib errors
They are not, glBindTexture() is an OpenGL function. The MSDN library page is here. Scroll to the bottom, it shows you the .h file that declares it (you already that right since the compiler didn't complain) and the .lib you need to link.
Right-click your project, Properties, Linker, Input, Additional Dependencies setting. Add opengl32.lib. Or to use the upvoted answer's suggestion, you can inject the linker directive in your source code:
#include <gl\gl.h>
#pragma comment(lib, "opengl32.lib")
Have you tried to pragma mark your library?
Like so:
#pragma comment(lib, "any.lib");
I added some boost stuff* to my code and the linking phase failed with:
error LNK2019: unresolved external symbol _IsolationAwareLoadLibraryA#4 referenced in function "void * __cdecl boost::interprocess::winapi::load_library(char const *)" (?load_library#winapi#interprocess#boost##YAPAXPBD#Z)
Can anyone help me figure this out? kernel32.lib is added in linker settings. I searched for _IsolationAwareLoadLibraryA and it doesn't seem to be present in Windows SDK 6.0A, which I'm using. The project is CLR if that matters.
*the boost stuff are two shared memory headers:
#include <boost/interprocess/shared_memory_object.hpp>
#include <boost/interprocess/mapped_region.hpp>
This functions are part of SDK 7.0A, and they should be inline (so there's no need to specify an .lib file). Try downloading and using a newer SDK, and make sure that ISOLATION_AWARE_ENABLED gets #defined, because this is what triggers the inclusion of those functions. I guess boost should define it by itself though.
It turned out the project I used had a "ISOLATION_AWARE_ENABLED=1" added to preprocessor definitions. Removing it fixed the linker error. Not sure whether this won't cause any other problems though. The disturbing fact is that I'm wasting lots of time just resolving various issues related to building my project with third-party C/C++ libraries.