On Thu, Jul 02, 2020 at 10:35:27AM +0200, Vít Ondruch wrote: > I just met something which might be of similar nature. Recent FF > 78.0-1.fc33.x86_64 fails to start with older glibc: > > > ~~~ > > $ firefox > XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so: > /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np, > version GLIBC_2.32 > Couldn't load XPCOM. > > ~~~ > > > Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to > glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless > issues like this are unexpected. There should be something, what would > force glibc update if FF requires more recent one. > There is nothing like that. This issue is not specific to glibc. If a library adds a symbol, it does not have to bump its soname. Thus on RPM level there won't be any change. If another executable starts using the new symbol, there won't be again no change on the RPM level. Therefore RPM finds a match at installation, but the dynamic linker finds a dissonance at run time. ELF RPM dependency generator could promote these linker symbol dependencies to RPM level, but I worry that most people will complain about growing YUM repository metadata. I don't think it's realistic to expect from the packagers that they will check and add these new dependencies manually. Teoretically, rpminpsect run in CI could catch these changes and warn the packager. But I worry that many people won't understand it and just keep ignoring it. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
