[BUG] Native plugin compiling fails on Windows (webrtc.lib error LNK2019: unresolved external symbol __std_reverse_copy_trivially_copyable_4)

[rollersteaam]

Describe the bug
Running build_plugin_win.cmd fails with a linker error. It might not have been able to link a dependency.

To Reproduce
Steps to reproduce the behavior:

1. Get a fresh clone of the project on a Windows 10 machine
2. Run build_plugin_win.cmd

Expected behavior
Building succeeds.

Screenshots

Environment (please complete the following information):

• OS: Windows 10 Pro 64-bit (10.0, Build 19043)
• Package version: 2.4.0-exp.2

Additional context
Full error message:

webrtc.lib(auto_correlation.obj) : error LNK2019: unresolved external symbol __std_reverse_copy_trivially_copyable_4 re
ferenced in function "public: void __cdecl webrtc::rnn_vad::AutoCorrelationCalculator::ComputeOnPitchBuffer(class rtc::
ArrayView<float const ,432>,class rtc::ArrayView<float,147>)" (?ComputeOnPitchBuffer@AutoCorrelationCalculator@rnn_vad@
webrtc@@QEAAXV?$ArrayView@$$CBM$0BLA@@rtc@@V?$ArrayView@M$0JD@@5@@Z) [C:\Users\Jordan\Desktop\sv-for-ml\Assets\com.unit
y.webrtc.simplyvideo\Plugin~\build64\WebRTCPlugin\WebRTCPlugin.vcxproj]
C:\Users\Jordan\Desktop\sv-for-ml\Assets\com.unity.webrtc.simplyvideo\Runtime\Plugins\x86_64\webrtc.dll : fatal error L
NK1120: 1 unresolved externals [C:\Users\Jordan\Desktop\sv-for-ml\Assets\com.unity.webrtc.simplyvideo\Plugin~\build64\W
ebRTCPlugin\WebRTCPlugin.vcxproj]

Weirdly, opening the webrtc.sln file in the build64 folder in Visual Studio 2019 and building ALL_BUILD completely succeeds.

My guess is that CMake is linking to an old version of the Microsoft Standard Library (STL) which lacks a definition of __std_reverse_copy_trivially_copyable_4. This would match the issue found in #434 where the wrong version of Direct3D was automatically included by CMake, causing build errors about missing code.

[rollersteaam]

Solution

For any developers having this issue, building the project using Visual Studio 2019 by opening build64/webrtc.sln is actually a valid solution for developing/building the native plugin on this project.

As stated in the first page of documentation for using the cmake program itself:

To build a software project with CMake, Generate a Project Buildsystem. Optionally use cmake to Build a Project, Install a Project or just run the corresponding build tool (e.g. make) directly. cmake can also be used to View Help.

Once build_plugin_win.cmd has run at least once, CMake sets up a completely usable Visual Studio C++ project.

Open up build64/webrtc.sln to develop on the native plugin. You may build by right clicking ALL_BUILD and clicking Build while in Visual Studio 2019. Using earlier versions of Visual Studio will likely cause an error that says "Missing v142 build tools".

Additional Notes

CMake, whose purpose is to simplify cross-platform development of C/C++ projects, has 2 uses:

1. CMake generates a build system for your current platform, allowing the project to be built via several methods. This is with the command cmake . -G "Visual Studio 16 2019" -A x64 -B "build64" inside build_plugin_win.cmd. If you're on Windows, this will be Visual Studio-based, creating the webrtc.sln file I mentioned. If you're on something else, it will create something else.
2. CMake will build your project by running your build system with select parameters, the command cmake --build build64 --config Release --target WebRTCPlugin inside build_plugin_win.cmd does this.

CMake generating a build system means it creates a Visual Studio C++ project ready for you to use, for building and for development.

However, the above issue is caused by CMake doing a bad job at its second use, building the project. The good news is you can just build it yourself via a different method.

By opening webrtc.sln in Visual Studio 2019 and building the ALL_BUILD project inside it, you can get it to all build successfully, resulting in automatic importing of the new dll into Unity for you to make immediate use of.

This error is likely caused by having multiple Visual C++ compilers on your computer and so isn't specific to this project.

[rollersteaam]

I've made a PR #443 that adds a message for this workaround in the native plugin README.

I'll leave this issue open unless you guys think #443 is an adequate solution to this issue or you guys come up with your own. A change to the CMake is probably the "full" solution, but probably unnecessary effort. I'm not knowledgeable enough on CMake to know if it's the solution or not.

[rollersteaam]

This seems like related helpful info tensorflow/tensorflow#17012

[karasusan]

Right, this issue should be fixed by changing CMakeLists.txt, but I am also not sure how to describe it.

[karasusan]

@rollersteaam
Can I close this ticket? Thanks.

[rollersteaam]

Sure thing :)