Stream: advent of code

Topic: Setting up environment (nix)

Juliano (Dec 01 2022 at 14:00):

anyone able to set up a nix shell with the latest main? i tried and it's complaining that

The package requires the Cargo feature called workspace-inheritance, but that feature is not stabilized in this version of Cargo (1.62.0).

what's weird is I tried to use nixpkgs-22.05 and nixpkgs-22.11 and both times it said Cargo 1.62 in the error. 22.05 had cargo 1.60, 22.11 has 1.64

Juliano (Dec 01 2022 at 14:00):

my very naive attempt so far https://github.com/omnibs/aoc22/blob/7b4917904c7742f32082b8f5f4dfebf6f43e8f9f/shell.nix

i had this working for an older version of main, but i want dbg :3

Juliano (Dec 01 2022 at 14:13):

ohh ok so the derivation for roc uses a pinned version of nixpkgs, but we can override it!

Juliano (Dec 01 2022 at 14:18):

ok overriding nixpkgs with 22.11 got me past that, but now I hit:

Compiling roc_docs v0.0.1 (/tmp/nix-build-roc-0.0.1.drv-0/2234iib1nswkawkigmaij7lg4gaf1fpp-roc-src/crates/docs)
Compiling roc_docs_cli v0.0.1 (/tmp/nix-build-roc-0.0.1.drv-0/2234iib1nswkawkigmaij7lg4gaf1fpp-roc-src/crates/docs_cli)
Finished release [optimized] target(s) in 2m 06s
Executing cargoInstallPostBuildHook
Finished cargoInstallPostBuildHook
Finished cargoBuildHook
buildPhase completed in 2 minutes 7 seconds
installing
Executing cargoInstallHook
cp: cannot stat 'target/x86_64-unknown-linux-gnu/release/lib/.': No such file or directory

Juliano (Dec 01 2022 at 14:39):

this seems to come from this postInstall override

Juliano (Dec 01 2022 at 14:58):

yeah, i don't have a lib/ dir at all
ive hundreds of files and a few other dirs, but no lib :S

Juliano (Dec 01 2022 at 14:59):

i think i recall richard mentioning something about a change to ship stdlib along with roc, maybe this postInstall was a part of that? no idea

Juliano (Dec 01 2022 at 15:01):

or unrelated, this postinstall seems pretty old

Richard Feldman (Dec 01 2022 at 15:07):

I don't think this lib dir is related to that one, but I could be wrong!

Juliano (Dec 01 2022 at 15:08):

i removed the cp line and it built, but running the hello world app fails :S

Downloading https://github.com/roc-lang/basic-cli/releases/download/0.1.1/zAoiC9xtQPHywYk350_b7ust04BmWLW00sjb9ZPtSQk.tar.br
    into /home/juliano/.cache/roc/packages

thread 'main' panicked at 'not yet implemented: TODO gracefully handle package install error IoErr(Os { code: 18, kind: CrossesDevices, message: "Invalid cross-device link" })', crates/compiler/load_internal/src/file.rs:3856:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

not sure what's the deal with cross-device. im on x86 linux building for x86 linux

unless somehow it's trying to link against a non-x86-linux platform??

Juliano (Dec 01 2022 at 15:09):

i pushed what i got to https://github.com/omnibs/aoc22/, need to bail now! will keep trying later tonight but welcome any help/contributions!

Héctor Ramón (Dec 01 2022 at 17:29):

@Juliano I hit this error today as well. I believe fs::rename is erroring because from and to are on different filesystems: https://doc.rust-lang.org/std/fs/fn.rename.html#errors

Héctor Ramón (Dec 01 2022 at 17:31):

I believe this is the cause: https://github.com/roc-lang/roc/blob/2a27d3c05f7974adf87e782704eab8d43c80652e/crates/packaging/src/cache.rs#L74

Richard Feldman (Dec 01 2022 at 18:12):

huh, interesting! I'm not sure what we want to do instead to make things work nicely with Nix here :thinking:

Richard Feldman (Dec 01 2022 at 18:13):

basically we want to download the package to a tempdir, then if it passes hash verification, mv it to ~/.cache/roc

Richard Feldman (Dec 01 2022 at 18:14):

I guess we could detect that specific error and cp instead in that case?

Héctor Ramón (Dec 01 2022 at 18:58):

Yes, that's what I was thinking as well.

Richard Feldman (Dec 01 2022 at 19:35):

@Héctor Ramón if you already have it building from source locally, can you confirm if replacing the rename with a cp fixes it?

Juliano (Dec 02 2022 at 00:18):

im sloooowly trying to fix it with https://docs.rs/fs_extra/1.2.0/fs_extra/dir/fn.move_dir.html

Héctor Ramón (Dec 02 2022 at 00:26):

Yeah, fs::copy works only with files.

Juliano (Dec 02 2022 at 00:49):

i got past that error but im getting

Error Os { code: 2, kind: NotFound, message: "No such file or directory" }

no idea where in the call stack

Juliano (Dec 02 2022 at 00:49):

still hunting

Juliano (Dec 02 2022 at 01:02):

so i randomly noticed i got a hello executable after running cargo run hello.roc on the first basic-cli example in the tutorial

and trying to run that executable i get bash: ./hello: No such file or directory which may be where that error is coming from

$ ls -l hello
-rwxrwxr-x 1 juliano users 20419168 Dec  1 21:51 hello
$ file hello
hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=61e0eead3cc4b065c941ea6fdb611db808a3e389, for GNU/Linux 3.2.0, with debug_info, not stripped

i am on x86-64 linux, so im puzzled why this executable is not running

Juliano (Dec 02 2022 at 01:06):

time for bed! my changes so far are in https://github.com/NoRedInk/roc/tree/fix-default-nix

Richard Feldman (Dec 02 2022 at 03:20):

oof, CrossesDevices is only available on Nightly Rust

Richard Feldman (Dec 02 2022 at 03:41):

PR to fix it: https://github.com/roc-lang/roc/pull/4653

Richard Feldman (Dec 02 2022 at 03:41):

I just had it always try a deep copy if the rename fails for any reason

Richard Feldman (Dec 02 2022 at 03:42):

I went with copy rather than rename because I think it should be less work; either way it has to copy the files, this way it just doesn't have to delete them one by one from the source directory - which is a tempdir, so the OS can probably clean it up more quickly than that regardless

Richard Feldman (Dec 02 2022 at 03:42):

lmk if that branch works for you!

Juliano (Dec 02 2022 at 09:39):

your branch works, but somehow it still produces an executable i can't run!

Folkert de Vries (Dec 02 2022 at 09:44):

any errors?

Juliano (Dec 02 2022 at 09:47):

@Folkert de Vries the "no such file or directory" above

Juliano (Dec 02 2022 at 09:47):

this

Folkert de Vries (Dec 02 2022 at 09:49):

ok, did we narrow down where that error originates?

Juliano (Dec 02 2022 at 09:51):

which error? the no such file or directory? or the one richard patched?

the one richard patched we narrowed down and it seems fixed

the no such file, i've no idea what up :<

Juliano (Dec 02 2022 at 09:51):

i read around the web no such file can happen when you have an incorrect arch executable, but it doesn't seem to be the case

Folkert de Vries (Dec 02 2022 at 09:52):

right I'd like to get a backtrace for it. did you set the RUST_BACKTRACE variable?

Juliano (Dec 02 2022 at 09:53):

$ RUST_BACKTRACE=1 cargo run a.roc
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/roc a.roc`
Error Os { code: 2, kind: NotFound, message: "No such file or directory" }

Folkert de Vries (Dec 02 2022 at 09:53):

ah I see, the problem is in the platform, not in the compiler

Folkert de Vries (Dec 02 2022 at 09:54):

you're using the cli platform?

Juliano (Dec 02 2022 at 09:54):

yeah

Juliano (Dec 02 2022 at 09:55):

so another weird data point, the nightly linux x86-64 is behaving the same for me

[nix-shell:~/git/roc]$ ./roc dev
bash: ./roc: No such file or directory

[nix-shell:~/git/roc]$ file roc
roc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=489d7a87d7eadbd6804a2f3edacf8022e9a08ea5, for GNU/Linux 3.2.0, with debug_info, not stripped

[nix-shell:~/git/roc]$ ls -l roc
-rwxr-xr-x 1 juliano users 84308912 Dec  1 06:27 roc

Folkert de Vries (Dec 02 2022 at 09:55):

can you try the rust_backtrace thing there?

Folkert de Vries (Dec 02 2022 at 09:56):

it should print more, really

Folkert de Vries (Dec 02 2022 at 09:56):

also what roc program are you running?

Juliano (Dec 02 2022 at 09:56):

the first basic-cli example in the tutorial

Juliano (Dec 02 2022 at 09:56):

sorry, try RUST_BACKTRACE=1 where this time?

Juliano (Dec 02 2022 at 09:57):

the contents of a.roc:

app "hello"
    packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.1.1/zAoiC9xtQPHywYk350_b7ust04BmWLW00sjb9ZPtSQk.tar.br" }
    imports [pf.Stdout]
    provides [main] to pf

main =
    Stdout.line "I'm a Roc application!"

Folkert de Vries (Dec 02 2022 at 09:58):

on linux

Juliano (Dec 02 2022 at 09:58):

oh, all of this is on linux

Folkert de Vries (Dec 02 2022 at 09:58):

ok

Folkert de Vries (Dec 02 2022 at 09:58):

well, that program should hit this piece of rust code

Folkert de Vries (Dec 02 2022 at 09:59):

#[no_mangle]
pub extern "C" fn roc_fx_stdoutLine(line: &RocStr) {
    let string = line.as_str();
    println!("{}", string);
}

Folkert de Vries (Dec 02 2022 at 09:59):

and nothing can really go wrong there, no file IO happens

Folkert de Vries (Dec 02 2022 at 09:59):

hmm it must be in the compiler itself then

Juliano (Dec 02 2022 at 10:00):

what i think is happening:

• some bit of cargo run compiles a.roc into hello
• some other bit just launches the executable

the 2nd part is failing bc linux is refusing to run the executable itself, at all

i read around the web this can happen when you have an incorrect arch binary, but it doesn't seem to be the case

Folkert de Vries (Dec 02 2022 at 10:00):

can you try just running the executable then, without invoking roc itself

Juliano (Dec 02 2022 at 10:01):

yeah, that's what i did here, and i get:

bash: ./hello: No such file or directory

even tho it has execute permissions, is an ELF 64bit executable which matches my OS, etc

Folkert de Vries (Dec 02 2022 at 10:02):

and the file is here?

Juliano (Dec 02 2022 at 10:02):

yep

Juliano (Dec 02 2022 at 10:02):

bizarre

Folkert de Vries (Dec 02 2022 at 10:02):

yeah that is kind of wild

Juliano (Dec 02 2022 at 10:02):

i get the same on the roc binary in the nightly

Juliano (Dec 02 2022 at 10:03):

file is there, file roc says all the right things, ldd roc shows my nix store stuff, +x is there, but ./roc gives me No such file or directory

Juliano (Dec 02 2022 at 10:10):

$ file target/debug/roc
target/debug/roc: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /nix/store/ynn1by1qdl16q6qwwh2h7zkgrn36c6i8-glibc-2.35-163/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, with debug_info, not stripped

$ file ~/Downloads/roc/roc
/home/juliano/Downloads/roc/roc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=489d7a87d7eadbd6804a2f3edacf8022e9a08ea5, for GNU/Linux 3.2.0, with debug_info, not stripped

so the first one is the roc built by cargo, which is a valid executable on my system (i can launch it just fine, it just produces executables i can't launch)

the second is the nightly binary that my system refuses to run

Juliano (Dec 02 2022 at 10:13):

differences:

• local binary says GNU/Linux, nightly says SYSV
• local binary's interpreter is glibc in the nix store, nightly binary is some missing /lib64 path
  • ldd on the nightly binary points ld-linux-x86-64.so.2 to the nix store tho, so this might be a red herring
• local binary is "for GNU/Linux 2.6.32", nightly is "for GNU/Linux 3.2.0"

Juliano (Dec 02 2022 at 10:19):

what is curious is the locally built roc binary works, but the stuff it produces, when the basic-cli platform is involved, won't launch

is it possible whatever is making the nightly binary an invalid executable on my system is also making any platform-specific binary styff in the platform invalid?

Juliano (Dec 02 2022 at 10:23):

i can repro on the nightly binary in a cloud bastion from work, also running nixos 22.05

Juliano (Dec 02 2022 at 10:26):

$ tar -zxvf roc_nightly-linux_x86_64-2022-12-01-d2d8511.tar.gz
...
$ ls -l roc
-rwxr-xr-x 1 juliano users 84308912 Dec  1 09:27 roc
$ file roc
roc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=489d7a87d7eadbd6804a2f3edacf8022e9a08ea5, for GNU/Linux 3.2.0, with debug_info, not stripped
$ ./roc
bash: ./roc: No such file or directory
$ uname -a
Linux bastion 5.10.126 #1-NixOS SMP Mon Jun 27 07:41:01 UTC 2022 x86_64 GNU/Linux

Anton (Dec 02 2022 at 11:06):

Hi @Juliano, I'm also on NixOS 22.05. The linux nightly does not work on NixOS but you can clone the repo and run:

nix develop
cargo build --release

Once that is done you can use:

./target/release/roc ~/myRocProject/main.roc

I'll make sure to mention this workaround for NixOS in the documentation

Juliano (Dec 02 2022 at 11:10):

@Anton thanks for confirming!

this also means we can't link to published platforms on NixOS, right?

if you try to compile a roc app with, say, packages { pf: "https://github.com/roc-lang/basic-cli/releases/download/0.1.1/zAoiC9xtQPHywYk350_b7ust04BmWLW00sjb9ZPtSQk.tar.br" }, the resulting binary will not run

Anton (Dec 02 2022 at 11:15):

Ah yes, I hadn't realized that yet but it makes sense.
I'll make a note to resolve that.
As a workaround; you can clone the basic-cli repo locally and use a path instead of a URL at pf:.

Juliano (Dec 02 2022 at 11:22):

thank you! that'll get me going :D

Juliano (Dec 02 2022 at 11:22):

btw, for my own learning, do you know what makes these binaries incompatible with nixos?

Anton (Dec 02 2022 at 11:23):

I'd suspect libraries that are dynamically linked in the nightly roc binary.

Georges Boris (Dec 04 2022 at 18:53):

Folks, I see we're not yet supporting MacOS 13 (Ventura) on the nightly releases so I decided to try and recompile Roc using nix from scratch (just to see how the current experience is going).

Georges Boris (Dec 04 2022 at 18:54):

I'm running into these issues:

error: failed to run custom build command for `roc_builtins v0.0.1 (/Users/georgesboris/code/roc/roc/crates/compiler/builtins)`

Caused by:
  process didn't exit successfully: `/Users/georgesboris/code/roc/roc/target/release/build/roc_builtins-a04181892e74d4fd/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  Compiling host ir to: /Users/georgesboris/code/roc/roc/crates/compiler/builtins/bitcode/builtins-host.ll
  Compiling 64-bit bitcode to: /Users/georgesboris/code/roc/roc/crates/compiler/builtins/bitcode/builtins-host.bc

  --- stderr
  thread 'main' panicked at '"zig" "build" "ir" "-Drelease=true" failed with:

    thread 155033 panic: Darwin is handled separately via std.zig.system.darwin module
  Unable to dump stack trace: debug info stripped

  ', crates/compiler/builtins/build.rs:223:21
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `roc_builtins v0.0.1 (/Users/georgesboris/code/roc/roc/crates/compiler/builtins)`

Caused by:
  process didn't exit successfully: `/Users/georgesboris/code/roc/roc/target/release/build/roc_builtins-a04181892e74d4fd/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  Compiling host ir to: /Users/georgesboris/code/roc/roc/crates/compiler/builtins/bitcode/builtins-host.ll
  Compiling 64-bit bitcode to: /Users/georgesboris/code/roc/roc/crates/compiler/builtins/bitcode/builtins-host.bc

  --- stderr
  thread 'main' panicked at '"zig" "build" "ir" "-Drelease=true" failed with:

    thread 155060 panic: Darwin is handled separately via std.zig.system.darwin module
  Unable to dump stack trace: debug info stripped

  ', crates/compiler/builtins/build.rs:223:21
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Georges Boris (Dec 04 2022 at 18:56):

being a Rust (a Nix) noob - I wonder if there is a quickfix I'm missing? I've reinstalled nix and running nix develop appears to work fine. Roc is freshly cloned.

Georges Boris (Dec 04 2022 at 18:56):

I'm running on an Intel macbook pro, not using the "new" ARM stuff.

Brendan Hansknecht (Dec 04 2022 at 18:57):

I don't think it is a rust issue. I think it is a zig version issue. We don't yet support zig 0.10.0 which I believe is required for macos 13

Brendan Hansknecht (Dec 04 2022 at 18:57):

I could be wrong, but my understanding is that it can't work on macos 13 until we upgrade zig, which also requires updating llvm and inkwell, which is a larger task in general.

Georges Boris (Dec 04 2022 at 18:58):

oh - so Roc is currently incompatible with macos 13 no matter what (and it will probably take a while before that changes)

Georges Boris (Dec 04 2022 at 18:59):

that's correct?

Brendan Hansknecht (Dec 04 2022 at 19:00):

That's my understanding. I think the current discussion was talking about targeting January for the change because this update could break things and we don't want to mess up advent of code.

Richard Feldman (Dec 04 2022 at 19:34):

yeah also llvm made a big breaking change, and the Rust library we use for llvm hasn't landed support for it quite yet: https://github.com/TheDan64/inkwell/pull/383 - that PR was approved at one point but hasn't gotten merged yet

Georges Boris (Dec 04 2022 at 19:35):

I guess I'm gonna do AoC entirely in our web REPL :nerd:

Georges Boris (Dec 04 2022 at 19:36):

Is the wasm repl up-to-date with nightly?

Michael Glass (Dec 04 2022 at 20:07):

@Georges Boris I'm doing it in a docker container. https://github.com/michaelglass/advent-roc

Marten (Dec 04 2022 at 21:34):

I've been using a nightly macos 12 release on M1 with Ventura via nix

Georges Boris (Dec 04 2022 at 23:39):

@Michael Glass ha! That will do! Thank you

Brian Carroll (Dec 05 2022 at 22:10):

Georges Boris said:

Is the wasm repl up-to-date with nightly?

Yes, it's deployed as part of the nightly build. But maybe docker is handier for you.

Last updated: Jul 06 2025 at 12:14 UTC