Can not dlopen a library using a protobuf message twice

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a dynamic library including protobuf message "a"
2. Create a driver (linked with protobuf) to dlopen and dlclose liba.so
3. In driver: dlopen liba.so, dlclose liba.so, dlopen liba.so

What is the expected output? What do you see instead?
Desired result is a successful second dlopen of liba.so
Actual result:
>libprotobuf ERROR google/protobuf/descriptor_database.cc:56] File already
exists in database: a.proto
>libprotobuf FATAL google/protobuf/descriptor.cc:857] CHECK failed:
generated_database_->Add(encoded_file_descriptor, size):
>Abort trap: 6 (core dumped)

What version of the product are you using? On what operating system?
protobuf-2.2.0, FreeBSD 7.0-RELEASE

Please provide any additional information below.
It seems that the dlclose results in the loss of the
protobuf_AssignDescriptors_once_ variable for the message allowing
DescriptorPool::InternalAddGeneratedFile to be called again on the next
dlopen. The behavior is expected given the circumstances, but it would be
helpful to have a way to allow the database collisions in this case.

Original issue reported on code.google.com by scott.m....@gmail.com on 8 Oct 2009 at 5:40

[GoogleCodeExporter]

The design of the protobuf library is currently such that if you unload a 
dynamic 
library containing a protobuf class, you *must* simultaneously unload the copy 
of 
libprotobuf that it is linked against.  Therefore, if you are writing a dynamic 
library which may be loaded and unloaded at runtime, you should probably 
statically 
link it against protocol buffers.

Alternatively, if you use:
  option optimize_for = LITE_RUNTIME;
and you do not use extensions, then I believe this will produce code that does 
not 
use any global registries and thus does not have these problems.

Original comment by kenton+protobuf@google.com on 12 Oct 2009 at 7:56

[GoogleCodeExporter]

Original comment by kenton+protobuf@google.com on 12 Oct 2009 at 7:56

• Changed state: WontFix

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can's try the second advise set "option optimize_for = LITE_RUNTIME;" as I 
need to use protobuf's descriptor and reflection，does the first advice really 
works? you say "probably"

Original comment by ssj...@gmail.com on 5 Nov 2012 at 3:01

[GoogleCodeExporter]

Statically linking libprotobuf into your dynamic library will work as long as 
protobufs are entirely encapsulated within your library's implementation and 
not exposed in the interface.  It may be a little tricky to convince gcc to 
link libprotobuf statically without linking everything statically, but it 
should be doable -- I think it works if you explicitly pass libprotobuf.a on 
the command line instead of the usual "-lprotobuf".

Original comment by kenton@google.com on 5 Nov 2012 at 6:54

[GoogleCodeExporter]

This assert causes problems even if you do not intend to unload the dynamic 
library, as it occurs on dlopen. Is it strictly necessary? Can it be replaced 
with an assert when the message definitions are different?

Original comment by richardg...@gmail.com on 1 Mar 2013 at 5:29