QtProtobuf's well-known types contradict reference implementation.

[semlanik]

Describe the bug QtProtobuf's well-known types contradict reference implementation.

@lubagov: I have some problem with the Empty type if I use QtProtobuf and link it along with the official implementation:

/Qt/5.15.2/gcc_64/include/QtProtobufProtobuf/google/protobuf/empty.qpb.h here has virtual destructor virtual ~Empty();

Also has type Empty: /build_grpc/protobuf-compiler/protobuf-3.12.4/src/google/protobuf/empty.pb.h and has virtual destructor virtual ~Empty();

Both have same namespace google::protobuf::Empty::~Empty and it mixing... so these classes don't call their own destructors.

[semlanik]

@lubagov I created a separate issue for this discussion.

Overall I think it makes sense to add a toggleable property to add an extra namespace to well-known types at least.

[lubagov]

I found, i can just use: LIBS += -lgrpc++ instance of:

CONFIG += link_pkgconfig
PKGCONFIG += grpc++

And seems it is not have conflict...

[semlanik]

Hmmm, doesn't it then overwrite QtProtobuf's google::protobuf::Empty::~Empty ?

[lubagov]

pkgconfig way also dependent of grpc and protobuf library:

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: gRPC++
Description: C++ wrapper for gRPC
Version: 1.30.2
Cflags: -I${includedir} 
Requires: grpc protobuf
Libs: -L${libdir} -lgrpc++
Libs.private: 

And seems, it is not happens anymore, if i not include libprotobuf in application. But... maybe the linking order has changed :-)

but in general, yes, if I have any library depending on the official Protobuf, well, let's say, for example, TensorFlow .. or FireBase ... then it will turn into a problem.