Fedora Account System
Red Hat Associate
Red Hat Customer
I'm trying to build llvm 21.1.0-rc1 in COPR (https://download.copr.fedorainfracloud.org/results/@fedora-llvm-team/llvm21/fedora-rawhide-x86_64/09283117-llvm/builder-live.log.gz) and it is failing because strip encounters an error trying to strip lto sections from a static archive containing only llvm bitcode files. What's interesting is when I debug this, I get a different behavior locally than when running in mock: Locally: bash-5.2# strip --version && sha1sum libompdevice.a && strip -R .gnu.lto_* -R .gnu.debuglto_* -R .llvm.lto -N __gnu_lto_v1 libompdevice.a GNU strip version 2.44.90.20250713 Copyright (C) 2025 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. eb47fddcb144a0faba448139df08fd33ec49ab54 libompdevice.a strip: libompdevice.a(libomptarget-amdgpu.bc): Unable to recognise the format of file: file format not recognized bash-5.2# echo $? 0 In Mock: <mock-chroot> sh-5.3# strip --version && sha1sum libompdevice.a && strip -R .gnu.lto_* -R .gnu.debuglto_* -R .llvm.lto -N __gnu_lto_v1 libompdevice.a GNU strip version 2.44.90.20250713 Copyright (C) 2025 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. eb47fddcb144a0faba448139df08fd33ec49ab54 libompdevice.a strip: libompdevice.a: file format not recognized <mock-chroot> sh-5.3# echo $? 1 Reproducible: Always
Created attachment 2097868 [details] Archive File
It sounds a little bit relevant to the forthcoming static-libraries-unstripped Fedora change. Current find-debuginfo (debugedit) in rawhide attempts to source-path-rewrite the .a files in the install tree (whereas it previously ignored them). But it should fail-safe so not break anything, including subsequent lto-stripping.
After doing some more debugging. The difference I'm seeing is because in the mock environment I have llvm-libs installed, but in my local system I do not. So having llvm-libs installed is what is causing the strip command to fail. This looks to be a regression in binutils, because when I use binutils-2.44-3.fc43, the command succeeds (still prints an error but has exit status 0) even with llvm-libs installed.
Hi Tom, OK, So I have tracked down the change in behaviour. It happens because the 2.44-3 strip does not have plugin support, whereas the 2.44.90 version does. The code to add support for plugins when running strip was added in response to a bug report/feature request for strip to be able to handle GCC LTO IR: https://sourceware.org/bugzilla/show_bug.cgi?id=21479 I suspect, but cannot prove, that a secondary issue is that the version of the LLVMgold.so plugin in llvm-libs for rawhide cannot handle the version of the bitcode information in the libomptarget-amdgpu.bc member of the libompdevice.a archive. So the plugin rejects the member as being unsupported/unrecognised which in turn causes strip to fail. One workaround is to force the 2.44.90 strip to load a plugin that will not look at bitcode files at all. eg: % strip -R .gnu.lto_* -R .gnu.debuglto_* -R .llvm.lto -N __gnu_lto_v1 libompdevice.a -o fred --plugin /usr/lib64/bfd-plugins/libdep.so strip: libompdevice.a(libomptarget-amdgpu.bc): Unable to recognise the format of file: file format not recognized % echo $? 0 Another - as you reported - is to not have the LLVMgold.so plugin installed at all. I appreciate that neither of these workarounds are really suitable for fixing build system failures introduced by this change. I am still pondering on the best way to solve this situation. I know that you would prefer that the 2.44-3 behaviour to be restored, but I do not want to compromise the new ability to strip GCC LTO information in archives. Cheers Nick
Right, the problem should be fixed by binutils-2.44.90-2.fc43 (I hope. It did work when I tested the libompdevice.a archive file, but I have not tried a full LLVM build). My chosen solution was to extend the code in strip so that if it fails to open an archive with the plugin enabled, it tries again this time without the plugin. That way I hope that the GCC LTO handling will still work, but in situations like this - where the plugin rejects the archive/file - the second attempt will succeed and strip will proceed as it did before. The build is currently in the Bodhi update system and should reach the buildroot later on today or possibly tomorrow.
I'm still seeing the same failure even with 2.44.902.fc43: https://download.copr.fedorainfracloud.org/results/@fedora-llvm-team/llvm21/fedora-rawhide-x86_64/09315754-llvm/builder-live.log.gz
*sigh*, OK, well the good news is that H.J. has created a different patch, one which I hope will work correctly. I am in the process of backporting this patch now.
Tom - OK, please retry with either binutils-2.44.90-4 or binutils-2.45-1.