Hi, it seems that muon's test suite tries to run x86-64 code on x86 architectures, and that obviously leads to test failures.
I'm not aware if this has been fixed in the latest master branch, as this issue has been reported by Debian's CI with the latest muon release (0.1.0). You can find the log here: https://salsa.debian.org/debian/muon-meson/-/jobs/3836747
[1/6] compiling assembly square_asm_cpp.p/square-x86_64.S.o FAILED: square_asm_cpp.p/square-x86_64.S.o c++ -g -Og -Wpedantic -Wextra -Wall -I . -I '../../../../../tests/project/common/118 llvm ir and assembly' -MD -MQ square_asm_cpp.p/square-x86_64.S.o -MF square_asm_cpp.p/square-x86_64.S.o.d -o square_asm_cpp.p/square-x86_64.S.o -c '../../../../../tests/project/common/118 llvm ir and assembly/square-x86_64.S' ../../../../../tests/project/common/118 llvm ir and assembly/square-x86_64.S: Assembler messages: ../../../../../tests/project/common/118 llvm ir and assembly/square-x86_64.S:34: Error: `retq' is only supported in 64-bit mode
P.S. yes, muon has been now accepted in Debian and will be part of the upcoming Debian 12 release :) (I had to rename the binary to muon-meson, but I'll be able to undo that in the next release, since the "other muon" has been removed a few days ago)
I have some vague memory that the platform detection code uses uname instead of the compiler defines, which triggers some interesting issues for multilib?
Il giorno dom 22 gen 2023 alle 18:18:10 +00:00:00, ~eschwartz email@example.com ha scritto:
the platform detection code uses uname instead of the compiler defines, which triggers some interesting issues for multilib?
What do you mean with multilib? As far as I can tell, that CI runner uses only i386 packages (compiler, libs, etc). But maybe the underlying kernel of the container's host is amd64, so that's what could be causing the issue?
-- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
~eschwartz is referring to https://todo.sr.ht/~lattis/muon/76, which could be the issue here, I'm not sure. 0.1.0 did pass all tests on all architectures alpine supports, so it seems likely that this is a case of muon reporting wrong system information.
It looks like
host_machine.cpu_family()is indeed incorrectly returning
x86_64based on the log output. Do you happen to know what
uname -mreports on that machine?
uname -mreports x86_64, which could explain why tests are failing.
But I'm a bit puzzled, what does
uname -mprint? The actual underlying CPU architecture or the kernel's target architecture? Because tests pass without issues on the "official" Debian build machines, which seem to run on amd64 even for i386 builds, possibly with an i386 kernel; since GitLab CI's uses containers, the kernel is shared between the container and the host, so
uname -mreports x86_64 for both. Does it make sense?
I'm unable to check if
uname -mreports i386 (or x86) on the build machines, so I can't confirm this.
cc -von the CI container: https://salsa.debian.org/debian/muon-meson/-/jobs/3840046
Build log of the official buildd: https://buildd.debian.org/status/fetch.php?pkg=muon-meson&arch=i386&ver=0.1.0-2&stamp=1674429200&raw=0
Edit: according to https://db.debian.org/machines.cgi?host=x86-ubc-02, the build machine linked above uses an x86-64 CPU, so it is probably running an x86 kernel in a VM
Well, uname is a program for reporting the running kernel information. Containers are really no different from installing an i386 package on an x86_64 OS, and only running that i386 package -- files you're not using really don't matter, whether you choose to not use them or a sandbox forbids you from using them.