Unreal Engine Integration failed: unresolved external symbol __std_reverse_trivially_swappable_8

[fweidner]

Hey folks!

I'm using protobuf with Unreal Engine 4.18.2.
Today, I wanted to upgrade to from 3.4.0 to 3.5.1

In my UE4 project, I'm linking against libprotobuf.lib

After having applied #4000 and commenting out "static_assert(std::is_pod::value, "");" in generated_message_table_driven.h I'm stuck again.

When compiling the UE4 project in Visual Studio 2017, I get the following two errors:
...
1>libprotobuf.lib(text_format.obj) : error LNK2019: unresolved external symbol __std_reverse_trivially_swappable_8 referenced in function "void __cdecl std::_Buffered_inplace_merge_divide_and_conquer2<class google::protobuf::Message const * *,__int64,class google::protobuf::Message const *,class google::protobuf::DynamicMapSorter::MapEntryMessageComparator>(class google::protobuf::Message const * *,class google::protobuf::Message const * *,class google::protobuf::Message const * *,__int64,__int64,struct std::_Temporary_buffer<class google::protobuf::Message const *> &,class google::protobuf::DynamicMapSorter::MapEntryMessageComparator,class google::protobuf::Message const * *,class google::protobuf::Message const * *,__int64,__int64)" (??$_Buffered_inplace_merge_divide_and_conquer2@PEAPEBVMessage@protobuf@google@@_JPEBV123@VMapEntryMessageComparator@DynamicMapSorter@23@@std@@YAXPEAPEBVMessage@protobuf@google@@00_J1AEAU?$_Temporary_buffer@PEBVMessage@protobuf@google@@@0@VMapEntryMessageComparator@DynamicMapSorter@23@0011@Z)

1>libprotobuf.lib(wire_format.obj) : error LNK2001: unresolved external symbol __std_reverse_trivially_swappable_8

1>F:\CloudStation\UE4\Plugin_C2IReceiver_cpp\Plugins\C2IReceiverPlugin\Binaries\Win64\UE4Editor-C2IReceiverPlugin.dll : fatal error LNK1120: 1 unresolved externals
...
`

With 3.4.0, I can compile it.

Does anyone have encountered the same error or has any suggestions for a fix?

EDIT: Error starts appearing with 3.4.1

[weliveindetail]

Hi fweidner, did you find a fix?

I face the same issue here with LLVM 3.8 on Windows 10. I get lots of these:
"error LNK2001: unresolved external symbol __std_reverse_trivially_swappable_8"

This comment suggests it to be an Visual Studio 2017 Update 3 issue (Do you have Update 3?). Apparently a library include path problem:
https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase-name-lookup-support-comes-to-msvc/#div-comment-421105

[fweidner]

@weliveindetail I've the most recent version of Visual Studio (15.5.3).

I just noticed that it 3.5.1 compiles when I use the cmake flag protobuf_MSVC_STATIC_RUNTIME.
(However this is not an option in my case, but anyways)

[weliveindetail]

Ok, in my case it happens when compiling with /MT (static runtime). So it's probably unrelated. Also with the Visual Studio 2015 toolchain (v140) I ended up having the same issue. As a hacky workaround I defined the symbols myself and throw exception("not implemented") on call. Didn't happen so far, maybe it's an unlikely code path..

Anyway, would be great to find an explanation.
Cheers

[snnn]

Hi @weliveindetail

How did you build these two software(protobuf and the one depends it), with VS 2015 or with 2017? Do you have VS 2015 and VS 2017 both installed on the same machine?

[pavel-kokolemin]

I did have similar problem too (unresolved external symbol __std_reverse_trivially_swappable_8). I have installed Visual Studio 2015 and compiler tools from Visual Studio 2017. My program is build using Visual Studio 2015 and I build protobuf with vcpkg and looks like it use Visual Studio 2017 toolset when available. I was able fix the problem (with the hint from @snnn) switching my program compiler to Visual Studio 2017.
I think this article might be related: https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017, notice that you can't link a program with a library that was compiled with a newer toolset.

Here is a stripped implementation of __std_reverse_trivially_swappable_8 from vector_algorithms.cpp just in case you want to keep old compiler (I don't know is it really safe):

static inline void _Reverse_tail(_BidIt _First, _BidIt _Last) throw() {
  for (; _First != _Last && _First != --_Last; ++_First) {
    const auto _Temp = *_First;
    *_First = *_Last;
    *_Last = _Temp;
  }
}
extern "C"  __declspec(noalias) void __cdecl __std_reverse_trivially_swappable_8(void * _First, void * _Last) noexcept {
  _Reverse_tail(static_cast<unsigned long long *>(_First), static_cast<unsigned long long *>(_Last));
}

[shirleyxy]

I met this problem too when I built with the VS2015 tools embedded in VS2017 IDE although it could be successfully built in VS 2017. I also try to built the same source codes in VS2010 and succeeded.

[xfxyjwf]

Feel free to send us a PR if there is a reasonable workaround. We do not maintain binary compatibility in general though.

[weliveindetail]

This bug has no relation to any of these projects and apparently there is no solution. It's just another mysterious hiccup in the Microsoft toolchain. Don't mix many versions on one machine and you may be lucky.

[Jamlee]

@snnn yes, i have vs2015 and vs2017 installed together too, Do you have any approach to solve it ?

[Jamlee]

I have both VS2015 and VS2017 installed but I build TF with VS2015 by using cmake -G "Visual Studio 14 2015 Win64". But this setting is not transmitted to the child builds and therefore external projects, including protobuf, are built with VS2017. And in this case the build fails with exactly the error reported here.

However, if I rename the VS2017 installation directory to some nonsense so that CMake cannot find it, then also the externals use VS2015 and the build succeeds. So apparently this problem arises from mixing two different toolsets.

[snnn]

@Jamlee Use this https://cliutils.gitlab.io/modern-cmake/chapters/projects/fetch.html to replace your "external projects,".