The Protobuf C++ library has NDR problems: When linking against protobuf compiled with -DNDEBUG, application code must also be compiled with -DNDEBUG

[mortie]

What version of protobuf and what language are you using?
Version: v21.2
Language: C++

What operating system (Linux, Windows, ...) and version? MacOS 12.4

What runtime / compiler are you using (e.g., python version or gcc version) Clang 14.0.6

What did you do?
Steps to reproduce the behavior:

1. Install a Protobuf library compiled with -DNDEBUG (this is the default)
2. Write some application code which somehow uses metadata_lite's InternalMetadata class (The code generated by protoc will do this)
3. Compile your application code without -DNDEBUG, and link with the protobuf library

What did you expect to see

I expect this to work.

What did you see instead?

The linker complains that it can't find the symbol for InternalMetadata::~InternalMetadata. This is because when -DNDEBUG is defined, the destructor is defined in the header and no symbol for it gets produced as part of the library, whereas without -DNDEBUG, the destructor is just declared in the header and declared in a source file.

Ideally, I should be able to compile my application code in debug mode while using a protobuf library compiled in release mode. But if not, the documentation and getting started guides should be changed to make it extremely clear that you must compile your application code with -DNDEBUG, or maybe -DNDEBUG should even be added to the packageconfig files.

Here's the linker error produced when compiling my application code in debug mode:

Undefined symbols for architecture arm64:
  "google::protobuf::internal::InternalMetadata::~InternalMetadata()", referenced from:
      google::protobuf::MessageLite::~MessageLite() in connection_state.pb.cc.o

[mortie]

Actually, closing this as a duplicate. When I checked yesterday there was no open issue about this problem but since then, #9947 and #10271 happened. Looks like there's good progress on this.