* Zephyrus Lykos via devel: > I've been working on > <https://fedoraproject.org/wiki/Changes/Protobuf_5.x/6.x> and testing > the packages in copr://mochaa/protobuf for the previous two years. > It's unviable to package Protobuf and gRPC as shared libraries without > introducing bugs in applications dependent on them. > > 1. Protobuf (and generally their consumers) doesn't account for > multi-consumer-in-one-process situations when shared. > Example: mozc, https://github.com/google/mozc/issues/387 > `libmozc.so`, the input engine, initializes protobuf on start. Its > `mozc_tool` executable, which doesn't depend on `libmozc.so` (and doesn't > have a need to), also initializes protobuf on start. > `mozc_tool` uses Qt, so `libmozc.so` will get loaded through the platform > input plugin. This triggers a crash in `libprotobuf.so`, because it shares > the global state between `dict_tool` and `libmozc.so`. `mozc_tool` and > `libmozc.so` trying to register the same proto twice will fail the CHECK().
So the issue here is that independent users of protobuf need separate copies of the code, and the way to achieve that is static linking? Apparently, the protobuf database is a global state that cannot be shared seamlessly between different protobuf users in one process? Could we use Debian's patch instead? <https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=721791;filename=protobuf-2.4.1-3.1.debdiff;msg=5> An alternative to static linking would involve loading multiple copies of the same object through dlopen, but this requires changes to the consumers and potentially glibc. > 2. gRPC depends on upb's internal global state. > Although upb's document says it does not have global state, it crashes on > tests if there are multiple definitions in different object files. This > should be an ODR violation, but ASan & UBSan both report nothing in this case. > Example A: https://github.com/grpc/grpc/issues/41613 > By default, gRPC has its own build of upb with visibility=default and follows > `BUILD_SHARED_LIBS`. However, Protobuf upstream says upb is not designed for > shared library usage and forces you to build a static library with > visibility=hidden. The issue still has TODOs? I find this very confusing. The proposed remedy (static-only builds) on its own will not make any of this better because static linking has fewer capabilities for symbol management. Thanks, Florian -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
