[UE4]链接LIBPROTOBUF的错误LNK2005
包装虚幻引擎4.27项目时，图书馆遇到了一个小问题。
我的项目包含 this Google的grpc库，我遵循这些用cmake构建它的步骤，然后将其包括在我的虚幻项目中。
此外，我的项目需要启用PixelStreaming插件。但是，这个插件似乎导入了另一个版本的Protobuf，该版本与包装相反，与GRPC中的包装相冲突。
The error is the following:
libprotobuf.lib(coded_stream.obj) : error LNK2005: "public: __cdecl google::protobuf::io::CodedOutputStream::CodedOutputStream(class google::protobuf::io::ZeroCopyOutputStream *，bool）”（?? 0codedOutputStream@io@protobuf@google @@ qeaa@peavereocopyOutputstream@peavereocopyoutputstream@123@_n@z）已在webrtc.lib（codeed_stream.obj）中定义了
。
我遇到了类似的问题因此，禁用GRPC对我来说不是一个可行的解决方案。
- 谁能建议如何“指示”构建的GRPC使用Pixel流插件现有的Protobuf库？
- 我需要采取哪些步骤才能正确配置这些相互矛盾的库？
Having a small issue with conflicting libraries while packaging an Unreal Engine 4.27 project.
My project contains this gRPC library from google and I followed these steps to build it with CMake and after include it in my Unreal Project.
In addition my project requires enabling PixelStreaming plugin. However it seems that this plugin imported another version of protobuf which, on packaging is conflicting with the one included in gRPC.
The error is the following:
libprotobuf.lib(coded_stream.obj) : error LNK2005: "public: __cdecl google::protobuf::io::CodedOutputStream::CodedOutputStream(class google::protobuf::io::ZeroCopyOutputStream *,bool)" (??0CodedOutputStream@io@protobuf@google@@QEAA@PEAVZeroCopyOutputStream@123@_N@Z) already defined in webrtc.lib(coded_stream.obj)
appearing for different objs.
I came across similar issues as such but disabling gRPC is not a feasible solution for me.
- Could anyone advise on how to "instruct" the built gRPC to use the existing protobuf library from Pixel Streaming plugin?
- Which steps do I need to take to properly configure these conflicting libraries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与GCP Libs有同样的问题。
这个问题似乎是由Protobuf的不良提交引起的（3.16.0由GRPC链接的分支似乎无法正确构建，似乎），
如果您构建了Protobuf手动的另一个分支并使用-DGRPC_PROTOBUF_PROVIDER = package
构建GRPC时的选项，您应该能够使它起作用。
我在MSYS环境中工作，所以不是1比1，而是我构建Protobuf和Grpc的命令。
//原子
c：/msys64/mingw64/bin/cmake.exe -h。 -bbuild -utput -g“ mingw makefiles” -dcmake_make_program = c：/msys64/mingw64/bin/ming/make/make/make.exe.exe -dcmake_c_compiler = c：/msysys64/mmsys64/mingw64/mingw64/bin/bin/gcc.exe-dcmake_comcmake_compirils64 mingw64/bin/g ++。exe -dcmake_install_message = never -dcmake_build_type = reparess -dbuild_shared_libs = on -dcmake_cxx_cxx_cantard = 17 -dprotobuf_build_tests = off -dprotobuf_tests = off -dprototobuf_prot_brot_brot_brcsl_absl grovider
=
c：/msys64/mingw64/bin/cmake.exe -h。 -bbuild -utput -g“ mingw makefiles” -dcmake_make_program = c：/msys64/mingw64/bin/ming/make/make/make.exe.exe -dcmake_c_compiler = c：/msysys64/mmsys64/mingw64/mingw64/bin/bin/gcc.exe-dcmake_comcmake_compirils64 mingw64/bin/g ++。exe -dcmake_install_message = never -dcmake_build_type =版本-dbuild_shared_libs = on -dcmake_cxxx_ctx_cand = 17提供者=软件包-DGRPC_PROTOBUF_PROVIDER =软件包-DGRPC_RE2_PROVIDER =软件包-DGRPC_SSL_PROVIDER =软件包-DGRPC_ZLIB_PROVIDER =软件包
构建Protobuf 3.20.x似乎对我有用（尽管ABSL与ABSL的问题进一步有问题）
having the same issue with GCP libs.
This issue seems to be caused by an bad commit of Protobuf (3.16.0 the branch linked by GRPC doesn't build correctly it seems)
If you build a different branch of protobuf manualy and use -DgRPC_PROTOBUF_PROVIDER=package
option when building gRPC you should be able to get this to work.
Im working in an msys environment so not 1 to 1 but my commands for building both protobuf and grpc are.
//protobuff
C:/msys64/mingw64/bin/cmake.exe -H. -Bbuild-output -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=C:/msys64/mingw64/bin/mingw32-make.exe -DCMAKE_C_COMPILER=C:/msys64/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/msys64/mingw64/bin/g++.exe -DCMAKE_INSTALL_MESSAGE=NEVER -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_STANDARD=17 -Dprotobuf_BUILD_TESTS=OFF -Dprotobuf_ABSL_PROVIDER=package
//gprc
C:/msys64/mingw64/bin/cmake.exe -H. -Bbuild-output -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=C:/msys64/mingw64/bin/mingw32-make.exe -DCMAKE_C_COMPILER=C:/msys64/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILER=C:/msys64/mingw64/bin/g++.exe -DCMAKE_INSTALL_MESSAGE=NEVER -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_STANDARD=17 -DgRPC_INSTALL=ON -DgRPC_BUILD_TESTS=OFF -DgRPC_ABSL_PROVIDER=package -DgRPC_CARES_PROVIDER=package -DgRPC_PROTOBUF_PROVIDER=package -DgRPC_RE2_PROVIDER=package -DgRPC_SSL_PROVIDER=package -DgRPC_ZLIB_PROVIDER=package
Building protobuf 3.20.x seemed to work for me (though having issues with absl further down the line)
解决我的问题的是迁移到UE5。
在UE5新项目中，使用上述GRPC项目的相同步骤。在UE5项目中，包装过程在没有链接冲突的情况下使用的第三个文件夹中具有libprotobuf.lib。不知道为什么UE包装这次不抱怨，但是有效的是有效的！
What solved my issue was migrating to UE5.
Using the same steps with aforementioned grpc project, in UE5 new project. Having a libprotobuf.lib in ThirdPary folder within UE5 project the packaging process worked with no LINK conflicts. Not sure why UE packaging did not complain this time but what works, works!