* mochaaP via devel: > 2026-02-16T10:04:23Z Florian Weimer <[email protected]>: > >> Could we use Debian's patch instead? > > Not completely, because there are far more shared states in libprotobuf than > this. > >> 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. > > libprotobuf and libupb makes its exported symbols' default visibility > as hidden. If you don't explicitly link with it on the ld command > line, it won't be used by the linker. And it also won't end up in the > final shared object's symbol table.
Okay, so it relies on a very specific combination of static and dynamic linking. On the Github issue, there's information that this is related to dlclose. An easier approach to deal with dlclose problems is linking the object with -z nodelete. Then dlclose won't unload it, and pointers registers with libprotobuf cannot become dangling due to that. 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
