Exporting Proto Classes from Shared Libraries

[Christoph Heindl]

Hi folks,

what are the reasons (if any) to recommend against exporting generated
proto classes from shared libraries, others than recompilation of
depending programs due to ABI changes?

From a (lazy) developer's perspective I think makes sense to use the
proto classes as property holders in a public API.

One more question: is it possible to specify the include directive for
the generated '.pb.cc' file? Currently, it searches for the '.pb.h'
file in the current directory, which is problematic if header and
source files go into different directories. Additionally, one need to
disable some 'dll interface' warnings on MSVC when exporting protobuf
classes from shared libraries. Is that possible?

Best regards,
Christoph

[Tom Swirly]

I personally don't see anything wrong with it.  In fact, since it's fairly easy to make your protocol buffers backward and forward compatible, I'd say it's probably better to expose protocol buffer classes than standard C++ classes or structs.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

--
     /t

http://radio.swirly.com - art music radio 24/7 366/1000

[Alexander Pensky]

The problem is the way the static initializers work.  If you export the classes from a .pb.cc file as part of a shared library (.so), their initializers will run every time you load the .so.   But these initializers need to add entries to tables which are in libprotobuf.so, and the same descriptor cannot be added twice.   So, anything that causes your message class .so to be loaded more times than the main protobuf .so is going to abort on a GOOGLE_CHECK at runtime.   For example, unloading and reloading the .so with dlopen(), or loading more than one .so module which has the message .so as a dependency.

(Note this is not an issue with Windows .DLL modules.)