Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Several shared object using same proto leading the the error: file already exists in database #1489

Closed
ye-ys opened this issue May 5, 2016 · 3 comments

Comments

@ye-ys
Copy link

ye-ys commented May 5, 2016

I have a project that have an c++ executable core, and several shared objects (.so, .dll) called plugins. When the core launches, it will load those plugins with dlopen. The core and plugins using protobuf as communication protocol, so they have to compile the generated .pb.cc and .ph.b files into their binaries to have the copy of the serializer/deserializer. And libprotobuf.so link to both the core and plugins. When I launch the core, it crushes with error: file already exists in database, same error in #863

I'm using protobuf-3 beta2, and Ubuntu 14.04. This error only happens on Linux. The program works fine on Windows and OS X.

I have also tried another way which compile all the generated protobuf files into a dynamic library (protocol.so), then the core and plugins were linked to protocol.so and libprotobuf.so. This works fine. Of course, because in #1062 the bug has been fixed. But when I changed the protocol.so into protocol.a, it failed again. I think it is same as compile generated .pb.cc separately.

I don't want to compile a protocol.so, because it is inconvenient for me to extend the communication protocol when I add more and more plugins. I think compile the generated .pb.cc into the plugin's binary is better (this work well on windows and OS X).

Any suggestions to fix this error are appreciated.

@xfxyjwf
Copy link
Contributor

xfxyjwf commented May 5, 2016

I believe the way we use globals in protobuf makes it impossible to link protos into separate dynamic libs and have protos in their public interfaces. The "file already exists in database" error is not hard to fix but I'm pretty sure that's not the only error you will see. I think you either need to avoid linking protos into separate .so, or try to use protobuf-lite where we don't have as much globals as we have for full runtime.

@gkl23
Copy link

gkl23 commented Sep 8, 2017

I had the same issue on windows7,I have a project that have an c++ executable core, and an shared objects (dll),When the core launches, it will load the library with LoadLibrary , it crushes with error.
vs2015 output:Microsoft C++ 异常: google::protobuf::FatalException
protobuf version:3.3.0

@hyphenlee
Copy link

@gkl23
load dll with protobuf generated .pb.h/cc file by LoadLibrary is more complicated, you can not load pb file in different dll. so all the *.pb.h/cc should only load in one dll. If you want to use protobuf class out of that dll , you shoud export it by __declspec(dllexport) under windows.

MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Jun 13, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Jul 4, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Jul 24, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Jul 28, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Aug 1, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Aug 1, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Aug 1, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Aug 1, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Aug 1, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
MrAnno added a commit to MrAnno/syslog-ng that referenced this issue Aug 1, 2023
- when compiling protos into a shared library, the shared library can not
be reloaded: protocolbuffers/protobuf#4126

- it is not recommended to have multiple shared libraries with protos
  compiled in them: protocolbuffers/protobuf#1489

Signed-off-by: László Várady <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants