Can't get it to compile on an aarch64(snapdragon 845) phone

[duckyondiscord]

The phone is running Arch Linux ARM, neither the AUR package nor manual compilation works, both of which throw a similar "Exec format error" shown below:

[ducky@archphone hid-xpadneo]$ make modules
git describe --tags --dirty >../VERSION
make -C /lib/modules/6.7.6-sdm845/build INSTALL_MOD_DIR="kernel/drivers/hid" LD=ld.bfd M=/home/ducky/git/xpadneo/hid-xpadneo/src VERSION="v0.9-171-g73be2eb" modules
make[1]: Entering directory '/usr/lib/modules/6.7.6-sdm845/build'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: aarch64-unknown-linux-gnu-gcc (crosstool-NG 1.24.0.508_c206f2f) 11.2.0
  You are using:           gcc (GCC) 14.1.1 20240507
  CC [M]  /home/ducky/git/xpadneo/hid-xpadneo/src/xpadneo.o
/bin/sh: line 1: scripts/basic/fixdep: cannot execute binary file: Exec format error
make[3]: *** [scripts/Makefile.build:243: /home/ducky/git/xpadneo/hid-xpadneo/src/xpadneo.o] Error 126
make[3]: *** Deleting file '/home/ducky/git/xpadneo/hid-xpadneo/src/xpadneo.o'
make[2]: *** [/usr/lib/modules/6.7.6-sdm845/build/Makefile:1911: /home/ducky/git/xpadneo/hid-xpadneo/src] Error 2
make[1]: *** [Makefile:234: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.7.6-sdm845/build'
make: *** [Makefile:12: modules] Error 2
rm ../VERSION
[ducky@archphone hid-xpadneo]$ 

I'm sorry if it's something stupidly simple that I missed, I just can't get it to work, and I know it should work on arm because I've heard of people around here compiling it on raspberry pis.

[duckyondiscord]

here's a full fastfetch in case it helps

[kakra]

Your kernel has been built with a cross-compiler - this won't work (likely it was built on an x86_64 architecture).

You can try env CHOST=aarch64-unknown-linux-gnu make modules or env CBUILD=aarch64-unknown-linux-gnu make modules. But this may still result in a non-working build. You should ask your distribution how to compile custom modules for that kernel.

OTOH, maybe your gcc configuration is broken. This is also something your distribution needs to fix.

If you get feedback, feel free to post the solution here so we can add it to the documentation. I'll think we'll see aarch64 a lot more often in the future.

[duckyondiscord]

The thing you mentioned about the compiler is different isn't really the main culprit, it proceeds just fine still after that, the line that seems to make it fail is /bin/sh: line 1: scripts/basic/fixdep: cannot execute binary file: Exec format error, there's seemingly a file it's trying to execute that's not built for arm64, which is weird.

[kakra]

the line that seems to make it fail is

Yes, because the build host of the kernel wasn't your native architecture. At least it looks like according to "exec format error". What's inside that script? Maybe it refers to a non-existing interpreter?

[duckyondiscord]

The thing is, I have no idea where the script it's mentioning actually is. I'm not finding it in xpadneo's repo anywhere.

[duckyondiscord]

I just tried installing openrazer-driver-dkms, it's the exact same error with the exact same script it's mentioning, maybe the headers are wrong?

[duckyondiscord]

I think I'll try to recompile the kernel locally and use the headers from there

[kakra]

The thing is, I have no idea where the script it's mentioning actually is. I'm not finding it in xpadneo's repo anywhere.

It's in the kernel headers or kernel sources. That script isn't shipped with any out of kernel modules.

It's created from a simple C source code file (fixdep.c), thus it has been compiled on the host as a build support file. Since your kernel was built on probably x86_64, fixdep has been built for x86_64.

You can probably temporarily fix that by going to the scripts/basic directory (location depends on the installed kernel package), and then run rm fixdep && make fixdep.

But this is really an issue your distribution has to fix: You've already discovered that even other packages fail in the same way.

[duckyondiscord]

Yeah there's way more x86 binaries in there, I think I need to locally recompile the kernel to fix it probably, thanks for all your help. Should I close this issue as it's not really up to you guys to fix?

[kakra]

Leave it open... We'll update the docs to point future users in the right direction. I'll close it with a commit. Feel free to post a bug report link for your distribution, so users who find this issue will have a quick way to check whether it was fixed.

Thanks. :-)

[duckyondiscord]

Thanks for all your help, I recompiled the kernel, exported the headers and it all works beautifully!