C++: x64-linker problem with ArenaString method ExplicitlyConstructed

[boro0607]

What version of protobuf and what language are you using?
Version: v3.21.08
Language: C++
OS: Windows 10
Compiler: MS VS 2022 Prof.
Toolset: 143
Language: ISO C++17 standard, ISO C17
SDK: 10.0.22
Package Manager: vcpkg, version 2022-11-10-5fdee72bc1fceca198fb1ab7589837206a8b81ba

What did you do?

1. Compiled protobuf (without zlib) using vcpck and triplets x86-windows-static / x64-windows-static
2. Compiled my code with referencing to resulting libs for x86 and x64
3. Code compiled/linked without any problems for win32/x86

What did you expect to see
Code to link for x64 as well (as it did using protobuf 3.10.0)

What did you see instead?
Linker error:
1>mylib.lib(messages.pb.obj) : error LNK2001: unresolved external symbol "class google::protobuf::internal::ExplicitlyConstructed<class std::basic_string<char,struct std::char_traits,class std::allocator >,8> google::protobuf::internal::fixed_address_empty_string" (?fixed_address_empty_string@internal@protobuf@google@@3v?$ExplicitlyConstructed@V?$basic_string@DU?$char_traits@D@std@@v?$allocator@D@2@@std@@$07@123@A)
1>mylib.lib(messages.pb.obj) : error LNK2001: unresolved external symbol "private: static char const * const * const google::protobuf::FieldDescriptor::kCppTypeToName" (?kCppTypeToName@FieldDescriptor@protobuf@google@@0QBQEBDB)
1>mylib.lib(messages.pb.obj) : error LNK2001: unresolved external symbol "void * const * const google::protobuf::internal::kGlobalEmptyTable" (?kGlobalEmptyTable@internal@protobuf@google@@3QBQEAXB)

Anything else we should know about your project / environment

1. The problem, does not occur when I link dynamically. However, for some reasons we may want to stick to static linkage.
2. The problem also occurs when I link the library statically but the CRT dynamically.
3. We use protobuf since three years to exchange data for a complex model. The model obviously contains string information. I noticed that changes to the MemoryArena have been applied and that the error appeared in the past. However, I found no hint to fix it.
4. We simply want to upgrade after a long period.

[jorgbrown]

It's odd that it would work with dynamic linkage but not static. Have you tried asking Microsoft?

[jorgbrown]

Assigning to Adam for triage.

[boro0607]

Nope, we haven't contact MS!

[arthur-tacca]

Have you tried printing out the full command line passed to the linker? (You can do then when building in the Visual Studio IDE by turning up the build verbosity in options.) You should verify that mylib.lib is earlier in the link line than protobuf.lib. If it is later (i.e. if your link line looks like "... protobuf.lib ... mylib.lib" then that would explain the linker error, and you would need to adjust your CMakeLists.txt to fix it (make mylib target depend on protobuf target, rather than both depended on from some higher-level target).

This may not be the problem, just an idea worth trying. Sorry if it is a distraction.

[boro0607]

Have you tried printing out the full command line passed to the linker? (You can do then when building in the Visual Studio IDE by turning up the build verbosity in options.) You should verify that mylib.lib is earlier in the link line than protobuf.lib. If it is later (i.e. if your link line looks like "... protobuf.lib ... mylib.lib" then that would explain the linker error, and you would need to adjust your CMakeLists.txt to fix it (make mylib target depend on protobuf target, rather than both depended on from some higher-level target).

This may not be the problem, just an idea worth trying. Sorry if it is a distraction.

Hi, the linker command seems to be fine. As mentioned, it works for 32 bit compilation, it only fails for 32 bit and only if linked statically.

Cheers,
SB

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.