mold: mold: fatal: unknown -m argument: armelf_linux_eabi
This happens when building the current version of freetype (2.11.1), with GCC patched to support -fuse-ld=mold as per https://github.com/skycocker/chromebrew/pull/6839
chronos@rpi4b-armv7l /usr/local/lib/crew/packages $ gcc -dumpmachine
armv7l-cros-linux-gnueabihf
chronos@rpi4b-armv7l /usr/local/lib/crew/packages $ mold --version
mold 1.1.1 (c1af9c97e763a1d521889191a83b27bd6c43b351; compatible with GNU ld)
meson.build:26:0: ERROR: Unable to detect linker for compiler "cc -Wl,--version -O2 -fuse-ld=mold"
stdout:
stderr: collect2 version 11.2.1 20220305
/usr/local/bin/ld.mold -plugin /usr/local/libexec/gcc/armv7l-cros-linux-gnueabihf/11/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc/armv7l-cros-linux-gnueabihf/11/lto-wrapper -plugin-opt=-fresolution=/usr/local/tmp/ccEVcbqi.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X -m armelf_linux_eabi -pie /usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11/../../../Scrt1.o /usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11/../../../crti.o /usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11/crtbeginS.o -L/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11 -L/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11/../../.. --version -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11/crtendS.o /usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/11/../../../crtn.o
mold: fatal: unknown -m argument: armelf_linux_eabi
collect2: error: ld returned 1 exit status
Happy to provide an armv7l docker container to replicate this if you want. (It runs fastest on a current Raspberry Pi 4B device running Ubuntu since that does the armv7l natively.)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 23 (12 by maintainers)
@satmandu Thanks for the explanation. Let me raise the priority of ARM32 support. It usually takes a week or so for me to add a new architecture, so it’s not very hard. It’s not very easy though, as what the linker does is essentially binary patching object files to combine them. If something is wrong, we need to dig into the machine code level.
By the way, the main readme file already contains the description as the supported architecture as follows:
I’m closing this bug as the original issue has been resolved. Feel free to file another bug if you have other issue.
To support
armv7l, one would need to create and fill in a new architecture fileelf/arch-arm32.cc, analogous to elf/arch-arm64.cc. That’s somewhere between 500 and 900 lines of code. The new architecture description could then be instantiated and referenced in elf/main.cc.