Open GoogleCodeExporter opened 9 years ago
Has anyone else tried this fix? Do we know if this patch (or the error that
lead to it) have been fixed in 2.4.3?
Original comment by w...@phrenotherapy.com
on 26 Apr 2012 at 4:28
I just tried this fix but it is not working. I will be trying to understand
why.
Original comment by montoya....@gmail.com
on 29 May 2012 at 2:15
what I did was to set LOG messages at
src/google/protobuf/descriptor_database.cc
and
src/google/protobuf/message.cc
to warnings, returning true in the first one.
I know it is not ok.
maybe we should follow the following advice:
http://code.google.com/p/protobuf/issues/detail?id=128
Original comment by montoya....@gmail.com
on 29 May 2012 at 3:47
Same problem. The patch did not fix my issue.
I am using protobuf 2.4.1 in Windows 7 and MingW (gcc version 4.4).
Original comment by asierg...@gmail.com
on 12 Jul 2012 at 9:28
We did not have this problem in Windows 7 with VisualStudio 2010
:(
Anyway, We finally decided to switch to apache thrift.
Original comment by montoya....@gmail.com
on 13 Jul 2012 at 10:57
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.
How to statically link it against protocol buffers? it really works ?
Original comment by ssj...@gmail.com
on 5 Nov 2012 at 2:58
you can use protobuf dynamic complier to avoid this problem
Original comment by ssj...@gmail.com
on 5 Nov 2012 at 4:49
using static library will not have this problem.I did.
reconfigure google buffer with :
configrue --disable-shared
before this step ,modify configure file at 2575 and 2578 line like this:
if test "x${ac_cv_env_CFLAGS_set}" = "x"; then :
CFLAGS="-fPIC"
fi
if test "x${ac_cv_env_CXXFLAGS_set}" = "x"; then :
CXXFLAGS="-fPIC"
than make ,it will be ok .
Original comment by ylee...@gmail.com
on 13 Jan 2013 at 3:21
This is an issue even if you are not unloading shared libraries. We see this
assert when dlopen loads a shared library containing a protobuf class that is
contained in a static library included by both the .so and the binary.
Can the assert changed to throw only when the message definitions are different?
Original comment by richardg...@gmail.com
on 1 Mar 2013 at 5:29
I attach a quick fix to test for identical duplicate message definitons. Build
libprotobuf.so with this & link to it with your .so and binaries.
How it works : The protoc generated file calls InternalAddGeneratedFile with
the message description first. If the message name is already present, and the
description matches, it skips the assert error. Since this call is first,
asserts in subsequent functions (eg. InternalRegisterGeneratedFile) are safe to
ignore as we know the message description is identical. Whilst this relies on
the current implementation, it is backwards compatible without an API change.
I've successfully applied this to 2.3.0.
Original comment by richardg...@gmail.com
on 6 Mar 2013 at 3:18
Attachments:
Great! My solution in the original post requires updating protoc compiler
(libprotoc.so*) and re-generating *.pb.cc files in application side and
rebuilding. But the patch in #10 fixes the problem just replacing
libprotobuf.so*. I hope this will be integrated in the future version of
protobuf.
Original comment by ek.k...@gmail.com
on 7 Mar 2013 at 4:21
The patch in comment #10 works for us as well. Is there any chance that it will
be merged? I can generate some code to help reproduce the problem if that would
help.
Original comment by scpet...@osrfoundation.org
on 3 Apr 2014 at 7:06
Original issue reported on code.google.com by
ek.k...@gmail.com
on 29 Jan 2012 at 5:55Attachments: