Description of problem: As described in #1836618 there is apparently a problem in binutils that causes the error message "nm: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32". This has been fixed in the "regular" binutils, but the error still shows up on Fedora when using e.g. x86_64-w64-mingw32-gcc with certain switches on Fedora. The binutils maintainer suggested using the patch in this comment to fix it: https://bugzilla.redhat.com/show_bug.cgi?id=1836618#c18 Version-Release number of selected component (if applicable): mingw-binutils-2.34-4.fc33 How reproducible: 100% with some commands Steps to Reproduce: 1. I get it when compiling my project that involves statically linking an .a library file. I think that might be a reliable setup to get it to happen. Actual results: I get an LLVMgold.so ELFCLASS32 error Expected results: No ELFCLASS32 error Additional info:
*** This bug has been marked as a duplicate of bug 1836618 ***
I filed this separate bug only because a Red Hat person suggested me to file a separate one for mingw-binutils specifically, so in that light duplicating it against that very original ticket where I was advised to do that seems a bit odd to me. Based on this I'm assuming this duplication was possibly made in error, perhaps because the specific conversation leading up to it was missed. I'll reopen this bug as a result, however if it was NOT marked duplicate unintentionally then please feel free to redo and I apologize for the noise in any case.
Right, I went a bit quick on this one, apologies.
No problem, I'm just happy my reopening wasn't a mistake on its own xD wasn't entirely sure I missed something myself. Anyways, sorry for the noise. I hope the info I provided is enough to get it fixed in MinGW's binutils too, it's not a big issue but the message caused by this bug is just a bit odd-looking and might have beginners think something went wrong when it didn't.
The mentioned patch does not cleanly apply to binutils-2.34, and would require backports of additional patches, which I'd rather avoid given this is not something that impacts binutils functionality. The fix will land in F34 with binutils-2.36.
/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 when building the 32bit part of wine. binutils.i686 2.35.1-41.fc34 binutils.x86_64 2.35.1-41.fc34
Same problem here - I updated to FC34 a couple of days ago and I noticed that the version for mingw binutils in FC34 is still at 2.34 (while the standard binutils is at 2.35.1 as pointed out above): mingw64-binutils-2.34-8.fc34.x86_64 mingw32-binutils-2.34-8.fc34.x86_64 Franco
I'll defer to Sandro's opinion here -- he says above that the fix is too invasive to backport.
binutils.i686 2.35.1-41.fc34 @fedora binutils.x86_64 2.35.1-41.fc34 @fedora I got this issue after building wine and installing it. The issue pops up, when the installation is running. /usr/bin/x86_64-w64-mingw32-ranlib: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 Ive read somewhere about a compiler flag to set, to make something not being stuck at the wrong ELF class, but forgot where.
rawfox: please note that that 'binutils' and 'mingwXX-binutils' are two different set of packages and while in FC34 the package binutils is at version 2.35.1, the packages for 'mingwXX-binutils' (XX=32 and 64) are still at version 2.34.8. This basically means that Sandro's comment on January 9th (https://bugzilla.redhat.com/show_bug.cgi?id=1913724#c5) didn't happen. On the other hand in Rawhide/FC35 the 'mingwXX-binutils' packages have been upgraded to version 2.36.1, so if you feel brave like me you can always run something like this: dnf --disablerepo=\* --enablerepo=rawhide upgrade mingw-binutils-generic mingw64-binutils mingw32-binutils and I can confirm you that upgrading 'mingwXX-binutils' to version 2.36.1 does indeed fix the 'wrong ELF class: ELFCLASS32' problem. Franco