there seems to be a nixos issue when testing code in a path that differs from the roc compiler directory
https://gist.githubusercontent.com/dankeyy/6497117f3f1550df6340733ed5de74d0/raw/39678d9d8133e11ce149fec6cc005bd93d6b545b/patherr.txt
I guess this is more of a nixos error than roc error? but still perhaps we could come to a solution for it
is it planned for the roc compiler itself to ever statically link with musl?
that would be so convenient
I think we've talked about it before but I don't remember what we concluded.
dank said:
there seems to be a nixos issue when testing code in a path that differs from the roc compiler directory
https://gist.githubusercontent.com/dankeyy/6497117f3f1550df6340733ed5de74d0/raw/39678d9d8133e11ce149fec6cc005bd93d6b545b/patherr.txtI guess this is more of a nixos error than roc error? but still perhaps we could come to a solution for it
Can you make an issue for this to improve the error message?
For now I think we should recommend using nix-build (using the default.nix). For a nicer long-term fix I expect we can patch the binary with the path we set in NIX_GLIBC_PATH but that may not be straightforward.
sure
:thinking: is there any reason we shouldn't statically link it with musl?
my immediate thought is "yeah let's do it!" but maybe there's a reason not to which I'm missing :big_smile:
we should consider a different default allocator then. and probably measure the perf
I thought we already switched to a nonstandard one awhile ago
could be misremembering
We use mimalloc currently
Also tested tcmalloc and jemalloc.
Tcmalloc was the fastest for me, but Linux only and more of a pain to get working, so mimalloc was chosen in the end.
nice! So is there any reason we shouldn't switch to musl on Linux?
not that I know of.
I was actually excited about https://github.com/thiagokokada/nix-alien
but it doesn't seem to work on the Roc binary (fails with an exception that originates from ldd's corrupted output)
maybe the roc binary depends on some stuff other than libgcc/glibc (for example who provides __snprintf_chk? one would've guessed glibc, but I have it installed..), I do not know
could be useful to just write up somewhere the total roc dependencies
right now it's kinda confusing at least to me which are roc compiler (as in building roc) dependencies and which are roc binary (dynamic) dependencies
it would also help avoiding issues like the rodio
/ alsa
dep in the future
:thinking: I wonder if we could have CI run ldd
on the executable and then if the output isn't exactly what we expect, fail the test - so that you couldn't accidentally introduce a new dynamic dep, you'd have to explicitly change that test
I've made #5067 for this
Last updated: Jul 06 2025 at 12:14 UTC