When trying to build the restraint package for Fedora 40, it failed because the linking libraries were ordered differently than F39 and F41. An earlier version of pkgconf 2.1.0 worked correctly when building the restraint package for Fedora 40. Debugging the problem showed the differences between F41 and F40 using the same srpm. Note where the "-L.../lib64 -lffi" snippets are when configure.ac creates GLIB_LIBS. Because the -lffi comes before -lgobject-2.0 in F40, libtool fails connect the dependency chain. -lffi needs to be specified after -lgobject-2.0 for libtool to work correctly and resolve the libffi symbols during linking. The working case (f41): libsoup-2.52.2/libsoup/Makefile:GLIB_LIBS = -L/builddir/build/BUILD/restraint-0.4.5-build/restraint-0.4.5/third-party/tree/lib -lgio-2.0 -lgobject-2.0 -L/builddir/build/BUILD/restraint-0.4.5-build/restraint-0.4.5/third-party/tree/lib/../lib64 -lffi -lgmodule-2.0 -lglib-2.0 -pthread -lm -lz -lselinux The non-working case (f40): libsoup-2.52.2/libsoup/Makefile:GLIB_LIBS = -L/builddir/build/BUILD/restraint-0.4.5/third-party/tree/lib/../lib64 -lffi -L/builddir/build/BUILD/restraint-0.4.5/third-party/tree/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -pthread -lm -lz -lselinux In f41, -lffi is added together with lobject-2.0 (as expected), while it isn't in f40. Since configure.ac seems correct, and I used the same source files for the build (same autoconf, same libtool as both are bundled), I'd suspect there is something wrong with pkgconf in f40. Building this under centos-stream 10 (which uses pkgconf-2.1.0) is successful. Downgrading my local environment to version 2.1.0, solves my problem locally. My guess is something between 2.1.0 and 2.1.1 broke things which is then resolved with 2.3.0 in F41. Reproducible: Always Restraint is the test harness used to run Beaker tests and thus is blocked from being updated.
Can we identify the post-2.1.1 fix for this? We generally prefer to go forwards rather than backwards in Fedora, so it'd be nicer to backport the fix rather than roll back to 2.1.0.
Looks like this was reported upstream at https://github.com/pkgconf/pkgconf/issues/361 and the recommendation was "use 2.2.0", but 2.2.0 comes with ABI changes and an soname bump so we really shouldn't do that. The fix was https://github.com/pkgconf/pkgconf/pull/345 , which is a lot of change. Perhaps what we should do is revert https://github.com/pkgconf/pkgconf/pull/339 , which is what broke this, and seems to have been only a performance improvement, not a functionality fix (so reverting it shouldn't *break* anything, just make complex cases slower).
Reverting that patch would work for me.
There does not seem to be a lot of commits between 2.1.0 and 2.1.1. This seems to be the most likely commit causing the issue: https://github.com/pkgconf/pkgconf/commit/80b5011e697d66065f8aaf88821ce95b3e3d1773 Let me see if I can prepare a build with this reverted...
(Oh man, this was stuck due to comment collisions, it's a bit late now...)
I see Adam is already on it: https://src.fedoraproject.org/rpms/pkgconf/c/464f5730acc4271233466772932209b6cd0e780a?branch=f40
FEDORA-2024-eae89af680 (pkgconf-2.1.1-2.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-eae89af680
FEDORA-2024-eae89af680 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-eae89af680` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-eae89af680 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-eae89af680 (pkgconf-2.1.1-2.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.