I don't yet fully understand why what is there currently doesn't work. Need to do a bit more research.

Minor correction, the type '2' is F_UNLCK as seen in the strace, the issue is the same.

The definition of F_SETLKW seems to not work with fcntl. I believe this is due to the hare definition actually referring to F_SETLKW64.

use rt;
use os;
use fs;

export fn main() void = {
	let f = os::create("test.lock", 0o644, fs::flags::RDWR)!;
	let F_WRLCK: i16 = 2; // Missing from rt currently.

	let lock_arg = rt::st_flock{ l_type = F_WRLCK,  ... };
	let fcntl_arg: rt::fcntl_arg = &lock_arg;
	
	// Works
	rt::fcntl(f: int, 7: int, fcntl_arg)!;

	// Fails
	rt::fcntl(f: int, rt::F_SETLKW: int, fcntl_arg)!;
};

strace:

execve("./bug", ["./bug"], 0x7fffe213a930 /* 61 vars */) = 0
openat(AT_FDCWD, "test.lock", O_RDWR|O_CREAT|O_NOCTTY|O_CLOEXEC, 0644) = 3
fcntl(3, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
fcntl(3, F_SETLKW64, 0x7ffcb9c983d0)    = -1 EINVAL (Invalid argument)

I noticed that _start is provided by libc, so I wonder how libc knows to invoke the hare initialization? I think it might be just jumping straight to main and skipping your initialization (and exit) code.

I have resolved this issue - the problem was nixos setting LD to 'ld' which meant hare was using ld even when -lc was passed. The symptom of this is a successful link, but the _start symbol is missing. This manifests as a segfault.

Another reproduction of the issue with -v:

https://builds.sr.ht/~ach/job/757977

hare is clearly using the wrong linker despite the fact -lc is being passed. No crt.o files are being linked, hence the missing _start.

edit: sorry this build doesn't show the issue, my mistake, will post another.

Ok after more digging, the program is being linked with ld, when it should be using $CC.

harec -o /run/user/1000/18e935ef9b76661c/temp.rt.0.ssa -N rt -t /home/ac/.cache/hare/rt/d9cd48a95d3312fe4cc7e40948de7e3b22a44e77f1f25a8e2e55649236dd72d7.td /home/ac/local/src/hare/stdlib/rt/+linux/+x86_64.ha /home/ac/local/src/hare/stdlib/rt/+linux/abort.ha /home/ac/local/src/hare/stdlib/rt/+linux/env.ha /home/ac/local/src/hare/stdlib/rt/+linux/errno.ha /home/ac/local/src/hare/stdlib/rt/+linux/platformstart+libc.ha /home/ac/local/src/hare/stdlib/rt/+linux/prctl.ha /home/ac/local/src/hare/stdlib/rt/+linux/segmalloc.ha /home/ac/local/src/hare/stdlib/rt/+linux/signal.ha /home/ac/local/src/hare/stdlib/rt/+linux/socket.ha /home/ac/local/src/hare/stdlib/rt/+linux/stat.ha /home/ac/local/src/hare/stdlib/rt/+linux/syscallno+x86_64.ha /home/ac/local/src/hare/stdlib/rt/+linux/syscalls.ha /home/ac/local/src/hare/stdlib/rt/+linux/types.ha /home/ac/local/src/hare/stdlib/rt/+x86_64/backtrace.ha /home/ac/local/src/hare/stdlib/rt/+x86_64/cpuid.ha /home/ac/local/src/hare/stdlib/rt/+x86_64/jmp.ha /home/ac/local/src/hare/stdlib/rt/abort.ha /home/ac/local/src/hare/stdlib/rt/ensure.ha /home/ac/local/src/hare/stdlib/rt/fenv_defs.ha /home/ac/local/src/hare/stdlib/rt/jmp.ha /home/ac/local/src/hare/stdlib/rt/malloc+libc.ha /home/ac/local/src/hare/stdlib/rt/memcpy.ha /home/ac/local/src/hare/stdlib/rt/memmove.ha /home/ac/local/src/hare/stdlib/rt/memset.ha /home/ac/local/src/hare/stdlib/rt/start+libc.ha /home/ac/local/src/hare/stdlib/rt/strcmp.ha 
qbe -o /run/user/1000/18e935ef9b76661c/temp.rt.1.s /run/user/1000/18e935ef9b76661c/temp.rt.0.ssa 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.2.o /run/user/1000/18e935ef9b76661c/temp.rt.1.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.3.o /home/ac/local/src/hare/stdlib/rt/+linux/syscall+x86_64.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.4.o /home/ac/local/src/hare/stdlib/rt/+x86_64/cpuid_native.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.5.o /home/ac/local/src/hare/stdlib/rt/+x86_64/fenv.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.6.o /home/ac/local/src/hare/stdlib/rt/+x86_64/getfp.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.7.o /home/ac/local/src/hare/stdlib/rt/+x86_64/longjmp.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.8.o /home/ac/local/src/hare/stdlib/rt/+x86_64/restore.s 
x86_64-unknown-linux-musl-as -g -o /run/user/1000/18e935ef9b76661c/temp.rt.9.o /home/ac/local/src/hare/stdlib/rt/+x86_64/setjmp.s 
x86_64-unknown-linux-musl-ar -csr /home/ac/.cache/hare/rt/d9cd48a95d3312fe4cc7e40948de7e3b22a44e77f1f25a8e2e55649236dd72d7.a /run/user/1000/18e935ef9b76661c/temp.rt.2.o /run/user/1000/18e935ef9b76661c/temp.rt.3.o /run/user/1000/18e935ef9b76661c/temp.rt.4.o /run/user/1000/18e935ef9b76661c/temp.rt.5.o /run/user/1000/18e935ef9b76661c/temp.rt.6.o /run/user/1000/18e935ef9b76661c/temp.rt.7.o /run/user/1000/18e935ef9b76661c/temp.rt.8.o /run/user/1000/18e935ef9b76661c/temp.rt.9.o 

The build driver is not picking up the assembly file containing the libc start symbol.

So my binaries with -lc are missing the _start symbol so just pick a random address then crash.

I was unable to get a working program using 'hare build -lc' or 'hare build -T +libc -lc' on nixos. I seem to have been able to reproduce the issue on alpine:

https://builds.sr.ht/~ach/job/757881