lld-link error compiling chromium with ffmpeg additional calls - c++

After adding some calls to ffmpeg from the ffmpeg_decoding_loop, I have errors when compiling on Windows (both directly on Windows and when cross-compiling from linux).
What I don't understand is that it works without an issue on linux/macos.
I have multiple calls to ffmpeg code but let's boil it down to a representative example.
I call this :
const AVFilter *buffer_src = avfilter_get_by_name("buffer");
On linux/macos : no problems.
On windows :
lld-link: error: undefined symbol: avfilter_get_by_name
>>> referenced by .\..\..\media\ffmpeg\ffmpeg_decoding_loop.cc:111
>>> obj/media/ffmpeg/ffmpeg/ffmpeg_decoding_loop.obj:(public: void __cdecl media::FFmpegDecodingLoop::InitFilterGraph(struct AVFrame *))
>>> referenced by .\..\..\media\ffmpeg\ffmpeg_decoding_loop.cc:112
>>> obj/media/ffmpeg/ffmpeg/ffmpeg_decoding_loop.obj:(public: void __cdecl media::FFmpegDecodingLoop::InitFilterGraph(struct AVFrame *))
Is there some additional configuration to be made on windows ?
I use visual studio 2019, windows 10.0.19041.0 sdk, llvm 10.0.0.

For those who may stumble on this : if you use functions from third_party/ffmpeg in your chromium code make sure those functions are specified in third_party/ffmpeg/chromium/ffmpeg.sigs.
It is only used when compiling for windows (that's why my mac/linux builds where succeeding).

Related

Unresolve external symbols when using v8.dll in my project

I'm new to making C++ project. I may be not sure prerequisite knowledge of C++ project.
[My environment]
Windows 10
Python 2.7.18
Developer Command Prompt for VS 2022
Visual Studio 2022 Community
I'm currently straggling with making V8 engine as a DLL and using it.
I've built V8 engine as a DLL successfly but using it I'm facing "Unresolve exteranl symbols" error.
Details:
error LNK2019: unresolved external symbol "class std::unique_ptr<class v8::Platform,struct std::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete<class v8::TracingController> >)" (?NewDefaultPlatform#platform#v8##YA?AV?$unique_ptr#VPlatform#v8##U?$default_delete#VPlatform#v8###std###std##HW4IdleTaskSupport#12#W4InProcessStackDumping#12#V?$unique_ptr#VTracingController#v8##U?$default_delete#VTracingController#v8###std###4##Z) referenced in function "public: __cdecl ezv8::Platform::Impl::Impl(void)" (??0Impl#Platform#ezv8##QEAA#XZ)
I've researched some thing that C++ mangling and compailer behaviours are.
I've noticed that the v8_libplatform.dll.lib file contains other type of mangled symbols like below.
?NewDefaultPlatform#platform#v8##YA?AV?$unique_ptr#VPlatform#v8##U?$default_delete#VPlatform#v8###__1#std###__1#std##HW4IdleTaskSupport#12#W4InProcessStackDumping#12#V?$unique_ptr#VTracingController#v8##U?$default_delete#VTracingController#v8###__1#std###45##Z = ?NewDefaultPlatform#platform#v8##YA?AV?$unique_ptr#VPlatform#v8##U?$default_delete#VPlatform#v8###__1#std###__1#std##HW4IdleTaskSupport#12#W4InProcessStackDumping#12#V?$unique_ptr#VTracingController#v8##U?$default_delete#VTracingController#v8###__1#std###45##Z (class std::__1::unique_ptr<class v8::Platform,struct std::__1::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::__1::unique_ptr<class v8::TracingController,struct std::__1::default_delete<class v8::TracingController> >))
As you can see, the .lib file contains the symbol with __1 namespace.
I found out why the file contains that. A bundled clang compiler compiles std namespace with inline namespace __1 but I'm not sure that how I can change compililng without __1 inline namespace.
Does anyone know how to change the compiler behaviour?
I resolved this problem myself. (But I get still other erros in building.)
What the problem is that I have to add a flag "is_clang = false" to gn args because the clang that is bound v8 will compile other type of manglings to MSVS.
If I added the flag then v8 tools will compile these code with cl.exe you installed.
I had exactly the same linking issue with v8::platform::NewDefaultPlatform() function, as well as some other methods like v8::Context::Scope::Scope(), v8::Context::Scope::~Scope() and so on. And the cause wasn't related with name mangling, it looks like clang-cl (used in v8/chromium by default on Windows platforms) uses the same name mangling as cl does. All these methods are defined in header files so they're effectively inlines, and clang-cl uses /Zc:DllexportInlines- compiler option which doesn't export inlines from DLLs (see https://reviews.llvm.org/D51340?id=172304 for details).
A request for adding /Zc:DllexportInlines option to cl compiler was raised a long time ago: https://developercommunity.visualstudio.com/t/implement-zcdllexportinlines-aka-fvisibility-inlin/374754 , but as of now, cl version 19.34.31937 still doesn't support it.
So I can see no way using v8 DLLs with Microsoft's cl compiler without modifying v8/chromium header files (which is never good). One can build v8 as static libraries, or use clang-cl as a custom build tool.
As for building v8 without clang using is_clang=false gn argument, I wonder if it's actually possible. There are many compiler options like -Wno-unused-const-variable or -Wno-unused-function which aren't supported by cl but added unconditionally in gn build files. I remember years ago it was possible to build chromium using cl, but is it now?

C++ Visual Studio 19 / OpenCV - Video Codex: Guide how to install mpeg4 library / header files needed

In principal I am capable to install 3rd party libraries to my VS 2019 Projects, at least have done it on several occasions in the past.
Unfortunatley I struggle to do so on the mpeg4 codex (also on others...).
I followed a few instructions, downloaded and added all .lib(s) and headers, but still fail with LINK2019 erros when compiling.
A short and simple guide would be highly appreciated.
If any other codex is easier, fine by me... (failed also on avi codecs :( )
Thanks in advance, T
#######################
Note: opencv4 fully installed with vcpkg and linked (all other cv2 features working)
Details to the error:
as soon as I add following line:
VideoWriter video(videofile, cv::VideoWriter::fourcc('M', 'J', 'P', 'G'), CamFPS, Size(CamY, CamX));
Following error:
LNK2019 unresolved external symbol "public: thiscall cv::VideoWriter::VideoWriter(class cv::String const &,int,double,class cv::Size,bool)" (??0VideoWriter#cv##QAE#ABVString#1#HNV?$Size#H#1#_N#Z) referenced in function _main xx C:\Users\xxx\source\repos\xx\xx\Source1.obj 1
What could be the problem?

Unresolved external link errors with generated DLL in Embarcadero C++ Builder

I am trying to use the AWS Iot SDK in Embarcadero C++ Builder which I am using the Embedded C Version of the SDK. I was trying to use a generated DLL in the RAD Studio IDE but wasn't able to input the functions needed as it was all under namespaces and classes.
Hence why I have resolved to using the Embedded C version of the SDK as talked about in this question because of it's portability. Calling DLL Functions under a namespace in RAD Studio
With the Embedded C version of the SDK, I have again generated it to be a DLL file where I have used the code below to export the data structures and functions with this example below:
#ifdef PUBSNUB_EXPORTS
#define PUBSNUB_API __declspec(dllexport)
#else
#define PUBSNUB_API __declspec(dllimport)
#endif
PUBSNUB_API IoT_Error_t aws_iot_mqtt_publish(AWS_IoT_Client* pClient, const char* pTopicName, uint16_t topicNameLen,
IoT_Publish_Message_Params* pParams);
PUBSNUB_API IoT_Error_t aws_iot_mqtt_subscribe(AWS_IoT_Client *pClient, const char *pTopicName, uint16_t topicNameLen,
QoS qos, pApplicationHandler_t pApplicationHandler, void *pApplicationHandlerData);
When I try to call these functions in RAD studio, I get the following errors, even with the generated lib file as instructed copied in the project folder. If I call these functions in a Visual Studio project, it will work completely fine.
[ilink32 Error] Error: Unresolved external '_iotClientConnectParamsDefault' referenced from C:\MICRO PLUS\RELEASE\MAINFORM.OBJ
[ilink32 Error] Error: Unresolved external '_iotClientInitParamsDefault' referenced from C:\MICRO PLUS\RELEASE\MAINFORM.OBJ
[ilink32 Error] Error: Unresolved external '_aws_iot_mqtt_publish' referenced from C:\MICRO PLUS\RELEASE\MAINFORM.OBJ
[ilink32 Error] Error: Unable to perform link
mangling
for static linking you need to use correct combination of switches of implib because your DLL was not created by BCC it contains most likely different name mangling ... try :
implib.exe -c -f -a winusb.lib winusb.dll
or any of the 8 combinations of the switches (rename the winusb with your file).
DLL must match the platform
so if you got 32 bit executable your DLL must be also 32 bit ... otherwise you need a bridge DLL ... In case of windows drivers beware that 32 bit EXE/DLLs on 64bit OS will run in WOW64 which might be problematic accessing real HW insteead of emulated one.
beware older implib versions do not handle 64bit DLLs (create empty 1024 byte libs)
if nothing works use dynamic DLL linkign
see Builder C++ calling VC++ class

cef project compile link error2001

I have downloaded the cef_binary_3.2840.1493.g4e029f4_windows32 to start my project with CEF.After I use cmake to build VS project,I use the VS2015 to compile the cef project(cef_simple),But it seems have some link error like this:
void __cdecl base::allocator::InsertAllocatorDispatch(struct base::allocator::AllocatorDispatch *)" (?InsertAllocatorDispatch#allocator#base##YAXPAUAllocatorDispatch#12##Z) cefsimple D:\cef\cefsimple\cef_sandbox.lib(malloc_dump_provider.obj)
And it make me confused because others can compile and run it successfully(his system is WIN10 64 with VS2013),so anybody can give me answer?
PS:my system is WIN7 64
workaround:
delete the string ../../debug/cef_sandbox.lib. (in project settings->Linker->input->AdditionalDependencies)
and also need delete in Defines: CEF_USE_SANDBOX
P.S. This problem described in 'https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial' and in comments of cefsimple_win.cc file. Reason of this error: cef_sandbox.lib linked in VS2013 and in new version VS it doesn't link. Another solution would be to use:
-DUSE_SANDBOX=OFF when running Cmake

Linker errors against custom built tcl85.lib, works against ActiveState distribution's tcl85.lib

We are building Tcl ourselves in order to distribute our own compiled binaries with an application. The application itself links against the Tcl library and uses the API internally.
To build Tcl we got the sources from http://sourceforge.net/projects/tcl/, we then navigate into the /win directory, change the buildall.vc.bat file to point to our MSVC installation and then we run that bat file. Building works as expected and outputs are produced in /win/Release_VC11. More specifically, tcl85.lib and tcl85.dll are produced.
When we link against this .lib from within our Qt C++ application, we get a bunch of linker errors. For example:
commands.obj : error LNK2019: unresolved external symbol __imp_Tcl_AppendResult
referenced in function "int __cdecl CallQMessageBox(void *,struct Tcl_Interp *,
int,char * * const)" (?CallQMessageBox##YAHPEAXPEAUTcl_Interp##HQEAPEAD#Z)
However, when we link against the tcl85.lib file provided as part of the ActiveState Tcl distribution, the linker does not have any issues and builds fine. We verified that its the exact same version of Tcl in both cases.
We are using MSVC 2012 (Express Edition) to build Tcl, and the build command remains unmodified in buildall.vc.bat:
::set OPTS=threads
if not %SYMBOLS%.==. set OPTS=symbols
nmake -nologo -f makefile.vc release OPTS=%OPTS% %1
We've been trying all sorts of things with not luck.
Ok, figured it out:
I was building Tcl as a 32bit binary instead of a 64bit one.
Replacing
call "D:\tools\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat"
with
call "D:\tools\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
and adding AMD64 to the nmake command like this
nmake -nologo -f makefile.vc release OPTS=%OPTS% %1 MACHINE=AMD64
in buildall.vc.bat seems to have fixed it.