Description of problem: + /usr/lib/rpm/find-debuginfo.sh -j8 --strict-build-id -m -i --build-id-seed 0.0.1-1.fc33 --unique-debug-suffix -0.0.1-1.fc33.x86_64 --unique-debug-src-base rust-pommes-0.0.1-1.fc33.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 -S debugsourcefiles.list /home/brain/rpmbuild/BUILD/pommes-0.0.1 explicitly decompress any DWARF compressed ELF sections in /home/brain/rpmbuild/BUILDROOT/rust-pommes-0.0.1-1.fc33.x86_64/usr/bin/mvn-genbr extracting debug info from /home/brain/rpmbuild/BUILDROOT/rust-pommes-0.0.1-1.fc33.x86_64/usr/bin/mvn-genbr nm: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 nm: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 original debug info size: 13544kB, size after compression: 12248kB /usr/lib/rpm/sepdebugcrcfix: Updated 1 CRC32s, 0 CRC32s did match. cpio: <::alloc::macros::format macros>: Cannot stat: No such file or directory cpio: <::core::macros::assert_eq macros>: Cannot stat: No such file or directory cpio: <::core::macros::assert_ne macros>: Cannot stat: No such file or directory cpio: <::core::macros::panic macros>: Cannot stat: No such file or directory cpio: <::core::macros::try macros>: Cannot stat: No such file or directory cpio: <::log::macros::__log_format_args macros>: Cannot stat: No such file or directory cpio: <::log::macros::log macros>: Cannot stat: No such file or directory cpio: <::serde::macros::forward_to_deserialize_any_method macros>: Cannot stat: No such file or directory cpio: <::std::macros::panic macros>: Cannot stat: No such file or directory Version-Release number of selected component (if applicable): binutils-2.34-4.fc33 How reproducible: Always. Steps to Reproduce: 1. Build rust-pommes package (or probably others) Actual results: Suspicious error about wrong ELF class. Expected results: No suspicious erros. Additional info: Not sure if this is bug in binutils, or anywhere else.
Hi Igor, Why is nm being asked to look at /usr/lib/bfd-plugins/LLVMgold.so ? This is for a 64-bit build of rust-pommes, yes ? So if any LLVM plugin needs examining, (and I am not sure why any should), then it ought to be /usr/lib64/bfd-plugins/LLVMgold.so and not /usr/lib/bfd-plugins/LLVMgold.so. When I tried to reproduce the problem in a fedora-rawhide-x86_64 mock environment the problem did not happen. Is it possible that the build is taking place in an environment that was also used to build the 32-bit version of rust-pommes ? Cheers Nick
I was building it locally and I have llvm-libs.i686 installed which contains that file. Can it be the reason? I was building 64bit version of rust-pommes locally, so I did not intend to use anything related to 32bit, but I do have that file due to other reasons.
(In reply to Igor Raits from comment #2) > I was building it locally and I have llvm-libs.i686 installed which contains > that file. Can it be the reason? Yes, but I guess the issue is, why is a 32-bit .so being pulled into the debugsourcefiles.list ? Do you know how this file is constructed ? I looked through my tes build environment but did not find a mention of it.
I tried to reproduce this in a container with llvm-libs.i686 installed, no luck. I also ran `alternatives --set ld /usr/bin/ld.gold`. Can you think of anything else that may be unusual about your environment?
(In reply to Josh Stone from comment #4) > I tried to reproduce this in a container with llvm-libs.i686 installed, no > luck. I also ran `alternatives --set ld /usr/bin/ld.gold`. Can you think of > anything else that may be unusual about your environment? Not sure, but I think I have this issue not only for Rust packages but basically for any kind of binaries which are compiled by GCC. I am really not sure what to provide, so just dump on me list of things to check and I will happily provide output.
Same issue here. Strace shows both stat("/usr/bin/../lib64/bfd-plugins/..", {st_mode=S_IFDIR|0555, st_size=229376, ...}) = 0 stat("/usr/bin/../lib64/bfd-plugins/LLVMgold.so", {st_mode=S_IFREG|0755, st_size=193888, ...}) = 0 openat(AT_FDCWD, "/usr/bin/../lib64/bfd-plugins/LLVMgold.so", O_RDONLY|O_CLOEXEC) = 5 as well as stat("/usr/bin/../bin/../lib/bfd-plugins/..", {st_mode=S_IFDIR|0555, st_size=40960, ...}) = 0 stat("/usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so", {st_mode=S_IFREG|0755, st_size=197740, ...}) = 0 openat(AT_FDCWD, "/usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so", O_RDONLY|O_CLOEXEC) = 5 Looking at the binutils source code /usr/src/debug/binutils-2.34.0-5.fc33.x86_64/bfd/plugin.c: 403: /* The intent was to search ${libdir}/bfd-plugins for plugins, but 404: unfortunately the original implementation wasn't precisely that 405: when configuring binutils using --libdir. Search in the proper 406: path first, then the old one for backwards compatibility. */ 407: static const char *path[] 408: = { LIBDIR "/bfd-plugins", BINDIR "/../lib/bfd-plugins" }; So the second entry of path is /usr/bin/../bin/../lib/bfd-plugins/, causing the observed behaviour. Looks like this isn't causing any misbehaviour, since the correct plugin dir is also searched, but it just causes the warning to be displayed.
OK - so there is not much I can do about the error message itself - it comes from the libdl library - but I have applied a small patch to the BFD library to provide some more context when the message is displayed. Specifically it should now say: nm: Failed to load plugin 'LLVMgold.so', reason: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 Which I think is a little bit clearer.
Assuming plugin names are unique, shouldn't the ones in BINDIR "/../lib/bfd-plugins" be skipped altogether if one with the same name was already loaded from LIBDIR "/bfd-plugins"?
(In reply to Sandro Mani from comment #8) > Assuming plugin names are unique, shouldn't the ones in BINDIR > "/../lib/bfd-plugins" be skipped altogether if one with the same name was > already loaded from LIBDIR "/bfd-plugins"? Hmm - this assumes that only one plugin needs to be loaded. Which is true at the moment, but might not be in the future. Possibly a better solution would be to try all plugins[*] and only generate warning messages if none of them could be loaded. (And also if there was at least one plugin that was tried). Or, alternatively, we could add a --plugin-verbose option which is passed to the BFD library and makes it describe the plugin loading and invoking process in detail. By default this feature would be disabled so warnings about unsupported plugins would be skipped. What do you think ? [*] This assumes that the automatically-load-plugins feature is being used, rather than the load-a-specifically-named-plugin feature.
Not really knowing the binutils code, but I had thought of something along the lines of - Go through and attempt to load plugins in LIBDIR "/bfd-plugins", keep track of the loaded plugins - Go through and attempt to load plugins from the fallback location BINDIR "/../lib/bfd-plugins", skip a plugin if one with the same name was already loaded from LIBDIR "/bfd-plugins"
(In reply to Sandro Mani from comment #10) > - Go through and attempt to load plugins in LIBDIR "/bfd-plugins", keep > track of the loaded plugins > - Go through and attempt to load plugins from the fallback location BINDIR > "/../lib/bfd-plugins", skip a plugin if one with the same name was already > loaded from LIBDIR "/bfd-plugins" That would not help if LIBDIR contained a plugin with a different name and also built for a different architecture. Eg if BINDIR contains FOOplugin.64bit.so and LIBDIR contains BARplugin.32bit.so then the warning message would still be displayed.
Yep true, if plugin names are not unique this approach won't work.
Right - I have updated the upstream binutils with a patch to suppress the error message when the BFD library is scanning for viable plugins. This patch will be brought in with the next rebase of the Fedora rawhide binutils, which should be happening in about a month's time.
*** Bug 1849335 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
x86_64-w64-mingw32-ar as in Fedora 33 right now still seems to exhibit this issue
(In reply to ell1e from comment #16) > x86_64-w64-mingw32-ar as in Fedora 33 right now still seems to exhibit this > issue Sorry, but x86_64-w64-mingw32 is not one of the architectures supported by the binutils package. Are you using the mingw-binutils package instead ? If so you should clone this BZ and change the component to mingw-binutils so that the maintainer of that package can fix it. I will upload a copy of the upstream patch here (git id: 13aa5ceb01c) so that it is easily available. Cheers Nick
Created attachment 1745279 [details] Upstream patch
Ok, I filed a ticket here: https://bugzilla.redhat.com/show_bug.cgi?id=1913724 thanks for your pointers!
*** Bug 1913724 has been marked as a duplicate of this bug. ***
Wasn't the point that it's not actually a duplicate since it's a different maintainer? That latest change seems counter-productive to me
(In reply to ell1e from comment #21) > Wasn't the point that it's not actually a duplicate since it's a different > maintainer? The bug is a duplicate. The maintainers are different. In particular the F33 binutils package is based on the 2.35 release of the upstream GNU Binutils project, whereas the F33 mingw-binutils package is based on the older 2.34 release. The 2.35 release already contains the patch that fixes this bug, but the 2.34 release does not. Hence the need for the patch. Cheers Nick
/usr/bin/x86_64-w64-mingw32-ranlib: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 I got this problem since a couple days on Fedora34. binutils.i686 2.35.1-41.fc34 binutils.x86_64 2.35.1-41.fc34 This error comes up after building wine, when installing the 32bit part of the biarch build.
(In reply to rawfox from comment #23) > /usr/bin/x86_64-w64-mingw32-ranlib: > /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 How is x86_64-w64-mingw32-ranlib being invoked ? Ie, what is the full command line ? In theory this error message should only be displayed if the plugin is explicitly named on the command line. If this command is being run inside wine, then is it possible that it is using the mingw-binutils package, rather than the binutils package ? The F34 version of mingw-binutils is based upon GNU BInutils 2.34, which does not have the fix to disable the error message when scanning plugin directories for potential plugins.
Created attachment 1789104 [details] wrong ELF class issues build output when building wine
Created attachment 1789105 [details] wrong ELF class issues in 64bit part build output from the 64bit part
(In reply to Nick Clifton from comment #24) > (In reply to rawfox from comment #23) > How is x86_64-w64-mingw32-ranlib being invoked ? Ie, what is the full > command line ? > > In theory this error message should only be displayed if the plugin is > explicitly named on the command line. > > If this command is being run inside wine, then is it possible that it is > using the mingw-binutils package, rather than the binutils package ? The Wine is built with 2 parts, a 32bit and a 64bit part, to be able to WoW64. First we build the 64bit part, wich already contains the issue, and then the second, 32bit part, wich also contains the issue. The logfiles are both added above^^ This problem started ~2 weeks before Fedora34 released and i upgraded. Before, everything was fine. Ive read an article about wrong or missing compilerflags, but really, thats all over my head. https://blogs.oracle.com/solaris/wrong-elf-class-requires-consistent-compiler-flags-v2 > F34 version of mingw-binutils is based upon GNU BInutils 2.34, which does > not have the fix to disable the error message when scanning plugin > directories for potential plugins. I may just need other binutils ?!
(In reply to rawfox from comment #27) > I may just need other binutils ?! What I think you need is a fixed mingw-binutils. This is a separate package from the standard "binutils" package and contains a set of the tools compiled especially for mingw targets. The fix should be to apply the upstream commit 13aa5ceb01cc to the mingw-binutils sources. I have reset the Component field of this BZ so that it will be assigned to the mingw-binutils maintainer. Cheers Nick
FEDORA-2021-054d1401df has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-054d1401df
Thank you for you work !
FEDORA-2021-054d1401df has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-054d1401df` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-054d1401df See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-054d1401df has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.