Description of problem: The google-benchmark build checks for librt and adds it to the generated CMake files in the -devel package if it was found. Since the last google-benchmark build, glibc 2.34 in Rawhide removed librt (and libdl and libpthread). See https://github.com/grpc/grpc/issues/26583 and https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7R4RBS2MD75S2MTY42L44IW3KOUT5K36/. Please rebuild google-benchmark in Rawhide so that > INTERFACE_LINK_LIBRARIES "/usr/lib64/librt.so" no longer appears in any of the generated CMake files, since this now breaks dependent packages that use CMake to configure their builds. Fow now, if you simply rebuild, it is replaced with > INTERFACE_LINK_LIBRARIES "/usr/lib64/librt.a" since glibc-devel still offers the static library. I am NOT convinced this is correct—I suspect it should be removed entirely—but I have not had a chance to try to test that. (This set of changes in glibc is going to be pretty messy distribution-wide, I suspect.)
librt.a will stay so that -lrt keeps working (the fact that it was missing was an accident/glibc packaging bug). I think this reference comes from some sort of build tool. Bug 1974966 was similar, but it doesn't really explain what happened. Does cmake hard-code paths it founds at package build time, instead of figuring them out when cmake is run for dependent packages, when their build environment is prepared? That's a bit odd.
> librt.a will stay so that -lrt keeps working (the fact that it was missing was an accident/glibc packaging bug). Ok, that seems to make sense. > I think this reference comes from some sort of build tool. Bug 1974966 was similar, but it doesn't really explain what happened. Does cmake hard-code paths it founds at package build time, instead of figuring them out when cmake is run for dependent packages, when their build environment is prepared? That's a bit odd. Yes, as far as I can tell that’s what’s happening. These .cmake files are getting generated during the build based on the build environment, and they include hard-coded paths to .so files (or .a files) instead of flags like “-lfoo”. Then they’re installed as part of the -devel package and used by dependent CMake builds. My experience with CMake isn’t deep enough (and/or I haven’t dug in deeply enough to this particular project) to say whether this is a standard CMake thing or something the google-benchmark developers have gone out of their way to encourage. To be honest, the CMake package system has always seemed overcomplicated to me (and I cut my teeth on autotools!)
(In reply to Ben Beasley from comment #2) > > librt.a will stay so that -lrt keeps working (the fact that it was missing was an accident/glibc packaging bug). > > Ok, that seems to make sense. > > > I think this reference comes from some sort of build tool. Bug 1974966 was similar, but it doesn't really explain what happened. Does cmake hard-code paths it founds at package build time, instead of figuring them out when cmake is run for dependent packages, when their build environment is prepared? That's a bit odd. > > Yes, as far as I can tell that’s what’s happening. > > These .cmake files are getting generated during the build based on the build > environment, and they include hard-coded paths to .so files (or .a files) > instead of flags like “-lfoo”. Then they’re installed as part of the -devel > package and used by dependent CMake builds. > > My experience with CMake isn’t deep enough (and/or I haven’t dug in deeply > enough to this particular project) to say whether this is a standard CMake > thing or something the google-benchmark developers have gone out of their > way to encourage. To be honest, the CMake package system has always seemed > overcomplicated to me (and I cut my teeth on autotools!) Tom, is there a way to find the set of packages we need to rebuild? Or even better, switch off this cmake behavior? Thanks.
This looks like a case where google-benchmark is telling CMake to pass an absolute library path to the linker instead of using -lrt, so there is not really any fix we can do for CMake. The only thing I can think of to figure out which packages need to be fixed would be to download cmake built -devel packages and grep for the library paths.
(In reply to Tom Stellard from comment #4) > This looks like a case where google-benchmark is telling CMake to pass an > absolute library path to the linker instead of using -lrt, so there is not > really any fix we can do for CMake. The only thing I can think of to figure > out which packages need to be fixed would be to download cmake built -devel > packages and grep for the library paths. The google-benchmark sources do not seem to contain the string "librt", which is why suspect that cmake is doing the conversion to the absolute path.
(In reply to Florian Weimer from comment #5) > (In reply to Tom Stellard from comment #4) > > This looks like a case where google-benchmark is telling CMake to pass an > > absolute library path to the linker instead of using -lrt, so there is not > > really any fix we can do for CMake. The only thing I can think of to figure > > out which packages need to be fixed would be to download cmake built -devel > > packages and grep for the library paths. > > The google-benchmark sources do not seem to contain the string "librt", > which is why suspect that cmake is doing the conversion to the absolute path. I think the full path is added via the LBIRT variable: https://github.com/google/benchmark/blob/main/src/CMakeLists.txt#L39
Any plans to rebuild this, with or without addressing the wider world of possible hard-coded library paths? Anything I can do to help? I’d love to be able to build grpc in Rawhide.
> Any plans to rebuild this, with or without addressing the wider world of possible hard-coded library paths? I don't know how to fix this correctly. Dependency on static library is not allowed by Fedora guidelines.
(In reply to Vitaly Zaitsev from comment #8) > I don't know how to fix this correctly. Dependency on static library is not > allowed by Fedora guidelines. librt.a is literally empty, so it does not count. It is just there so that -lrt continues to work. If you want to keep using -lrt for compatibility with earlier Fedora versions, that's fine.
> librt.a is literally empty, so it does not count. It is just there so that -lrt continues to work. If you want to keep using -lrt for compatibility with earlier Fedora versions, that's fine. It will add dependency on glibc-static package: $ dnf -C provides '/usr/lib64/librt.a' Last metadata expiration check: 23:44:20 ago on Fri 09 Jul 2021 13:22:45. glibc-static-2.33-5.fc34.x86_64 : C library static libraries for -static linking. Repo : fedora Matched from: Filename : /usr/lib64/librt.a
rawhide is different: $ mock -r fedora-rawhide-x86_64 --dnf-cmd -- -C provides /usr/lib64/librt.a […] Finish: chroot init No matches found for the following disable plugin patterns: local, spacewalk glibc-devel-2.33.9000-34.fc35.x86_64 : Object files for development using : standard C libraries. Repo : fedora Matched from: Filename : /usr/lib64/librt.a Finish: run $ It is expected that a simple rebuild will cause cmake to fix the file reference, without adding a dependency on glibc-static.
> rawhide is different: It makes sense. Thanks. Build completed: google-benchmark-1.5.5-3.fc35.
The rebuilt package works as expected for me. Thanks to Vitaly for the rebuild, and thanks to Florian and Tom for helping look in to the problem and for providing very useful details on what to expect.