On Sun, Jun 27, 2021 at 08:54:20PM +0200, Florian Weimer wrote: > I've pushed a new glibc build to rawhide (glibc-2.33.9000-29.fc35) that > auto-generates versioned dependencies on glibc if symbols within the > under-development symbol version are used, where the ELF-derived RPM > dependencies are inaccurate. Given the change to the startup code, this > affects all programs in this release cycle, and the libdl and libpthread > changes mean that most shared objects trigger the versioned dependency > as well. I noticed this change has affected the build of a C library that I did just now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1777714 $ rpm -qR libnbd-1.9.2-1.fc35 glibc >= 2.33.9000-36.fc35 ... This means of course that the library can't be installed without upgrading to bleeding-edge glibc. I understand that it's Rawhide, but still that seems a bit excessive?! (For context we often install hand-picked Rawhide packages in older Fedora in order to gain specific new features - in this case optimized nbdcopy.) > The dependencies are conservative in the sense that you might a > dependency on a more recent glibc version than that is actually > required by the symbols used. Is there a way to find out if the dependency is real or conservative? According to nm -D we're using these symbols from future glibc: U pthread_getspecific@@GLIBC_2.34 U pthread_key_create@@GLIBC_2.34 U pthread_key_delete@@GLIBC_2.34 U pthread_setspecific@@GLIBC_2.34 Obviously these symbols are nothing new, but I suppose this might be related to -lpthread no longer being a separate library? > For the technical background, here's what I put into a comment within > the dependency generator itself: > > # A glibc development snapshot (say version 2.33.9000) may define > # symbols in its under-development symbol version (GLIBC_2.34). RPM This seems applicable. > # automatically derives RPM dependencies such as > # libc.so.6(GLIBC_2.34)(64bit) from that. While the GLIBC_2.34 > # version is under development, these dependencies may be inaccurate > # and could be satisfied by glibc RPM package versions that lack the > # symbols because they were created from an earlier development > # snapshot that had some other GLIBC_2.34 symbols. Therefore, if the > # latest, under-development ELF symbol version is detected, this > # dependency generator adds an explicit RPM dependencies on the glibc > # packaging version against which an RPM package is built. This explains what happened in this case (I guess?) but still leaves me wondering why pthread_* APIs could be affected by this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
