* Richard W. M. Jones: > 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.) That wouldn't work anyway for this rawhide cycle because so many new symbol versions had to be added (including __libc_start_main@@GLIBC_2.34, which is used by *all* main programs). >> 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? Correct, older glibc won't be able to load this version of the library because libpthread isn't linked in anymore. If the processes that needs libnbd has linked in libpthread, it might have worked by accident on older glibc without the new symbol versions. But that would be very obscure failure mode. So we added new symbol versions to make it explicit that a new glibc version is needed. Basically, that caused the dependency switched from libpthread.so.0(GLIBC_2.2.5)(64bit) to libc.so.6(GLIBC_2.34)(64bit). And because of the __libc_start_main change (which we had to do for security hardening purposes), I thought it was not such a significant additional burden to do it for the former libpthread symbols, too. Which is why I don't look too hard at fancy ways to avoid the symbol version change. In the next rawhide cycle, I expect that the auto-generated versioned dependency applies to fewer builds. Thanks, Florian _______________________________________________ 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
