~tachi

Italy

https://andrea.pappacoda.it

Faccio cose

Trackers

~tachi/miniman

Last active 1 year, 9 months ago

#81 Tests failing on i386 1 year, 4 months ago

Comment by ~tachi on ~lattis/muon

uname -m reports x86_64, which could explain why tests are failing.

But I'm a bit puzzled, what does uname -m print? 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 -m reports x86_64 for both. Does it make sense?

I'm unable to check if uname -m reports i386 (or x86) on the build machines, so I can't confirm this.

Output of uname -m, uname -a, env and cc -v on 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

#81 Tests failing on i386 1 year, 4 months ago

Comment by ~tachi on ~lattis/muon

Il giorno dom 22 gen 2023 alle 18:18:10 +00:00:00, ~eschwartz outgoing@sr.ht 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

#81 Tests failing on i386 1 year, 4 months ago

Ticket created by ~tachi on ~lattis/muon

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

For example:

[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)

#26 PATH_MAX is not always defined 2 years ago

Ticket created by ~tachi on ~lattis/muon

It seems that you unconditionally use PATH_MAX in muon, but POSIX does not require that macro to be defined, it says that it should only be defined if the OS has an hard limit on path length.

From the Posix specification, in <limits.h>, under the section "Pathname Variable Values": "A definition of one of the symbolic constants in the following list shall be omitted from the <limits.h> header on specific implementations where the corresponding value is equal to or greater than the stated minimum, but where the value can vary depending on the file to which it is applied."

For example, GNU Hurd does not define the macro.

In their guidelines (under the section PATH_MAX, MAX_PATH, MAXPATHLEN, _POSIX_PATH_MAX) they give some advice about how to handle this situation, but I believe that setting PATH_MAX to the same size of MacOS or Linux (with something like #ifndef PATH_MAX ...) should be enough.

#23 DESTDIR support 2 years ago

Comment by ~tachi on ~lattis/muon

Sorry, it actually is supported, I don't know I missed it 😅️

I plan to integrate muon in my CI pipelines though, so stay tuned for other reports ;)

Edit: I don't know how to close the ticket :/

#23 DESTDIR support 2 years ago

Ticket created by ~tachi on ~lattis/muon

Hi! First of all, thank you for doing this! A C port of Meson is absolutely needed to support exotic platforms. For example, Meson's reliance on Python 3 is a blocker for OpenSSL.

Does Muon plan to support DESTDIR and/or --destdir? It would be really important for Debian and other distros.

Thanks again :)