Ah, I see. In that case I think you're right that it would be best to put
the symbols in separate namespaces for client and server. The protocol
compiler does not have any special support for this, but you could
accomplish it by having two .proto files which are identical except that
one says package my.project.server while the other says package
my.project.client for example. This requires some caution, though, because
if the two .proto files are edited concurrently then they could end up
introducing different or incompatible new fields with conflicting field
numbers. Depending on your setup you might be able to have just a single
.proto file committed in your repository and have the other version of it
generated as part of your build with a simple sed script that replaces the
On Wed, Jun 22, 2016 at 3:34 PM, Steve Beckert <s.w.beck...@gmail.com>
> Thanks for the reply.
> Unfortunately sharing compiled proto symbols between Client and Server is
> not an option for me as Client and Server are independently deployable and
> bump their proto version independently. It sounds like putting the proto
> symbols in a unique namespace per component would be an option to avoid
> violating the ODR. Is this an option for the protoc code generator?
> On Wednesday, June 22, 2016 at 9:28:16 AM UTC-5, Adam Cozzette wrote:
>> I sounds to me like this symbol duplication is causing a C++ ODR
>> (one-definition rule) violation, which could explain the crashes you have
>> seen. I would try moving the compiled proto symbols into a separate library
>> and have both the client and server libs depend on that same library so
>> that there is no duplication of the proto symbols.
>> On Tue, Jun 21, 2016 at 6:54 AM, Steve Beckert <s.w.b...@gmail.com>
>>> 1 process with 2 components - a client and a server
>>> Both Client and Server make use of a Model.proto
>>> Client and Server are built with different versions of Model.proto
>>> Server generates .h and .cc files at buildtime and compiles them into
>>> libServer.so. Sever's use of the proto is contained solely within
>>> Client also generates .h and .cc files at buildtime and builds a library
>>> libClientProto.so. Client's use of the proto is in a different library
>>> libClient depends on both libServer and libClientProto
>>> How do I guarantee at runtime that libClient uses libClientProto to
>>> create proto classes instead of libServer, since both libClientProto and
>>> libServer supply the same proto symbols?
>>> Even though Client and Server communicate with serialized proto objects,
>>> if Client was built with version 1 of Model.proto but Server was built with
>>> version 2, I see crashes when destructing proto classes due libClient using
>>> libServer for its proto.
>>> I know a better approach would be to ensure the proto .cc files are
>>> compiled into the same library where the proto classes are used, but how
>>> can I prevent a future Client2 making this same mistake above?
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to protobuf+u...@googlegroups.com.
>>> To post to this group, send email to prot...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to email@example.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.