Building from source · beginners

I've run through the Building from Source guide a few times, building llvm in different ways. Does anyone have some insight on what I need to do to fix this? Thanks!

Folkert de Vries (Sep 14 2020 at 23:51):

Richard Feldman (Sep 15 2020 at 00:11):

Bob Shelline (Sep 15 2020 at 14:05):

Richard Feldman (Sep 15 2020 at 14:08):

Richard Feldman (Sep 15 2020 at 14:09):

if you have any edits to the instructions that might help the next person get up and running on Windows, a PR would be great!

Bob Shelline (Sep 15 2020 at 14:12):

Haha, that's the trick. I'm not sure what I was doing wrong. It may be that I was missing the Python or CMake dependencies that I installed while trying the Zig guide that Folkert linked. Ultimately I went through the steps in the Roc guide again with nmake and it worked.

Bob Shelline (Sep 15 2020 at 14:14):

Bob Shelline (Sep 15 2020 at 14:16):

Ju Liu (Mar 26 2021 at 12:30):

Anton (Mar 26 2021 at 12:35):

What version do you see on brew info llvm? It might be llvm 11 and I'm confident that version will not work. I'm currently using 10.0.1.

Ju Liu (Mar 26 2021 at 12:37):

yep, can confirm it doesn't. the readme above suggests using 10.0.0_3 which is what I'm trying

Ju Liu (Mar 26 2021 at 12:47):

$ brew info llvm
llvm: stable 10.0.0 (bottled), HEAD [keg-only]
Next-gen compiler infrastructure
https://llvm.org/
/usr/local/Cellar/llvm/10.0.0_3 (7,055 files, 1GB)
  Poured from bottle on 2021-03-26 at 12:36:37
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/llvm.rb
==> Dependencies
Build: cmake ✘, python@3.8 ✘
Required: libffi ✔
==> Requirements
Build: Xcode ✔
==> Options
--HEAD
    Install HEAD version
==> Caveats
To use the bundled libc++ please add the following LDFLAGS:
  LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"

llvm is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

If you need to have llvm first in your PATH, run:
  echo 'export PATH="/usr/local/opt/llvm/bin:$PATH"' >> /Users/arkham/.bash_profile

For compilers to find llvm you may need to set:
  export LDFLAGS="-L/usr/local/opt/llvm/lib"
  export CPPFLAGS="-I/usr/local/opt/llvm/include"

==> Analytics
install: 18,593 (30 days), 68,307 (90 days), 234,327 (365 days)
install-on-request: 15,100 (30 days), 54,439 (90 days), 185,622 (365 days)
build-error: 0 (30 days)

Ju Liu (Mar 26 2021 at 12:47):

$ cargo run repl
   Compiling roc_builtins v0.1.0 (/Users/arkham/code/roc/compiler/builtins)
   Compiling cc v1.0.67
   Compiling rand_core v0.6.2
   Compiling directories-next v2.0.0
   Compiling colored v2.0.0
   Compiling dirs-next v2.0.0
   Compiling petgraph v0.5.1
   Compiling backtrace v0.3.56
   Compiling spirv_headers v1.5.0
error: failed to run custom build command for `roc_builtins v0.1.0 (/Users/arkham/code/roc/compiler/builtins)`

Caused by:
  process didn't exit successfully: `/Users/arkham/code/roc/target/debug/build/roc_builtins-abe28cf79a8a01a1/build-script-build` (exit code: 101)
  --- stdout
  Compiling zig object to: /Users/arkham/code/roc/compiler/builtins/bitcode/builtins.o
  Moving zig object to: /Users/arkham/code/roc/target/debug/build/roc_builtins-8a0ab0a538352427/out/builtins.o
  Compiling ir to: /Users/arkham/code/roc/compiler/builtins/bitcode/builtins.ll
  Compiling bitcode to: /Users/arkham/code/roc/target/debug/build/roc_builtins-8a0ab0a538352427/out/builtins.bc

  --- stderr
  thread 'main' panicked at 'llvm-as-10 failed: No such file or directory (os error 2)', compiler/builtins/build.rs:78:24
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Ju Liu (Mar 26 2021 at 12:48):

Ju Liu (Mar 26 2021 at 12:49):

oh, is it because it's trying to run llvm-as-10, while the locally installed version is just llvm-as?

Ju Liu (Mar 26 2021 at 12:51):

Ju Liu (Mar 26 2021 at 12:54):

    Finished dev [unoptimized + debuginfo] target(s) in 2m 18s
     Running `target/debug/roc repl`
  The rockin' roc repl
────────────────────────
Enter an expression, or :help, or :exit/:q.
» 1 + 100
101 : Num *

Ju Liu (Mar 26 2021 at 13:06):

Anton (Mar 26 2021 at 13:16):

:+1: I think the CI error could be because we're not using the latest rust version on CI yet, I'll check it out.

Anton (Mar 26 2021 at 13:25):

Peter Fields (Mar 27 2021 at 12:53):

I am getting errors when building from source. I am on MacOS and I've tried the steps in the troubleshooting section. Can someone help me?
╰─ cargo run repl
Compiling roc_builtins v0.1.0 (/Users/motionstatic/ws/dev/roc/compiler/builtins)
Compiling cgmath v0.18.0
Compiling im-rc v14.3.0
Compiling im v14.3.0
Compiling crossbeam-deque v0.7.3
Compiling im v15.0.0
Compiling im-rc v15.0.0
Compiling thiserror v1.0.24
Compiling rand v0.7.3
Compiling serde v1.0.124
error: failed to run custom build command for roc_builtins v0.1.0 (/Users/motionstatic/ws/dev/roc/compiler/builtins)

Caused by:
process didn't exit successfully: /Users/motionstatic/ws/dev/roc/target/debug/build/roc_builtins-7f77b815e7e30688/build-script-build (exit code: 101)
--- stdout
Compiling zig object to: /Users/motionstatic/ws/dev/roc/compiler/builtins/bitcode/builtins.o

--- stderr
thread 'main' panicked at 'zig failed: Unable to create builtin.zig: file not found
', compiler/builtins/build.rs:75:17
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Zeljko Nesic (Mar 27 2021 at 13:23):

Peter Fields (Mar 27 2021 at 15:30):

Anton (Mar 27 2021 at 15:39):

Hi Peter, we're currently using zig 0.7.1, I'll make sure to add that to the zig section of BUILDING_FROM_SOURCE.

Folkert de Vries (Mar 28 2021 at 12:54):

apparently the install instructions give you llvm 11 now on macos at least. Can we find instructions to get a specific version?

Folkert de Vries (Mar 28 2021 at 12:55):

we use llvm 10 for the moment; also need to upgrade that at some point but that'll cause a bunch of breakage/frustration probably

Ju Liu (Mar 28 2021 at 12:58):

Folkert de Vries (Mar 28 2021 at 13:00):

Lucas Rosa (Mar 28 2021 at 15:10):

Richard Feldman (Mar 28 2021 at 15:36):

Inkwell supports LLVM 11 now, so in theory we could update our fork to take advantage of that

Mario (Apr 14 2021 at 21:15):

So it's like 6 hours later and the nix build still seems to be going... is this normal? :thinking:

Seems to have selected an awfully large number of packages which appear to all be building from scratch?

Lucas Rosa (Apr 14 2021 at 21:53):

kind of, LLVM takes super super long to build. depends on how much power your machine has, so hard to say if 6hrs itself is normal

Lucas Rosa (Apr 14 2021 at 21:54):

I'm going throw the pain now cause I just switched to linux, also I think the nix setup is broken at the moment

Mario (Apr 14 2021 at 22:52):

trying https://ziglang.org/builds/zig-macos-x86_64-0.7.1.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 403
error: cannot download zig-macos-x86_64-0.7.1.tar.xz from any mirror
builder for '/nix/store/m4a7fps28v1qh7v12dyfgx96899j7h97-zig-macos-x86_64-0.7.1.tar.xz.drv' failed with exit code 1
building '/nix/store/zmlxwgfzagln7yqg14c00g6xd0mq1gjj-python-2.7.18.drv'...
cannot build derivation '/nix/store/2y7qyxdlgg9qmbwcclylmd9myqac4c2a-zig-0.7.1.drv': 1 dependencies couldn't be built

Lucas Rosa (Apr 14 2021 at 23:21):

oofff. for macOS I just downloaded a pre-built llvm and mapped some ENV vars myself

Lucas Rosa (Apr 14 2021 at 23:32):

the error that made think nix was messed up is happening to me without nix, so forget what I said

Richard Feldman (Apr 15 2021 at 00:39):

Richard Feldman (Apr 15 2021 at 00:40):

I think you might be the first one to try building Roc on M1 hardware, so I have no idea what to expect there, on Nix or otherwise :laughing:

Richard Feldman (Apr 15 2021 at 00:40):

I think @Brendan Hansknecht has built it successfully on a Raspberry Pi though, which also runs on ARM, but that was awhile ago and I don't think it was on Nix :thinking:

Richard Feldman (Apr 15 2021 at 00:44):

seems like it's missing from the Nix store - Roc's standard library is written in https://ziglang.org/ so the zig executable needs to be on your PATH to build Roc - I forget if there's a way to add mirrors to Nix derivations, but the file it's looking for is hosted here on the Zig website: https://ziglang.org/download/0.7.1/zig-macos-x86_64-0.7.1.tar.xz

Richard Feldman (Apr 15 2021 at 03:10):

Lucas Rosa (Apr 15 2021 at 05:43):

Mario (Apr 15 2021 at 22:31):

Mario (Apr 16 2021 at 16:36):

Tarjei Skjærset (May 13 2021 at 15:44):

I'm struggling to get anywhere on macOS, I've been trying since yesterday to get llvm installed. Not really sure which direction I need to be going in. Some things I have tried:

So I'm not really sure what my next step here is. Am I missing something obvious, or do I need to set up a Linux environment?

Lucas Rosa (May 13 2021 at 15:52):

@Tarjei Skjærset on macos I never managed to even build LLVM from source, not even with llvmenv (which is what I use on linux)

I recommend two options:
1) use nix and nix-shell which should be working
2) download a pre-built llvm for macos and add this function to your .bashrc/.zshrc

llvminit() {
  export LLVM_SYS_100_PREFIX=$HOME/Downloads/llvm
  export PATH=$PATH:$HOME/PATH_TO_ROC_REPO/nix/bin:$HOME/Downloads/llvm:$HOME/Downloads/llvm/bin
}

Lucas Rosa (May 13 2021 at 15:54):

then everytime I start a new terminal session and switch to the roc folder I run llvminit first and everything should work

Lucas Rosa (May 13 2021 at 15:55):

Lucas Rosa (May 13 2021 at 15:56):

Tarjei Skjærset (May 13 2021 at 15:59):

Is the nix-shell supposed to be working without llvm explicitly installed? I tried running cargo run repl earlier, but assumed the reason it didn't work was because I hadn't gotten the llvm installation working. As for 2), I'm guessing that's essentially what I was doing when I tried downloading the binaries, but the issue I ran into there was with macOS' security model where it just won't run stuff unless you allow it in the privacy & security thingy - which I tried, but there are just so many executables.

Lucas Rosa (May 13 2021 at 15:59):

Lucas Rosa (May 13 2021 at 16:00):

it could be that the nix setup on mac is broken, it didn't work for me over a month ago suddenly and I gave up on it

Tarjei Skjærset (May 13 2021 at 16:00):

Ohh okay, well I'm happy to rely on nix-shell (although hadn't heard about it before), so that's a separate problem then

Lucas Rosa (May 13 2021 at 16:00):

so to allow the binaries to run, you just quickly open system preferences and hit allow

Lucas Rosa (May 13 2021 at 16:01):

it should show up in the Security & Privacy section of system preferences after you try to run it the first time

Tarjei Skjærset (May 13 2021 at 16:02):

Yeah I did try that , but there were literally tens of them. I didn't get it to work, so I scrapped it and tried other stuff, but I'm happy to try that again. Give me a second to uninstall everything else, and I'll give the prebuilt binaries a go again

Lucas Rosa (May 13 2021 at 16:04):

oh I see gotcha, I was only prompted for like 2 of them, I wonder if you can enable them via the CLI and do it all in one go

Lucas Rosa (May 13 2021 at 16:05):

for the rust version, you probably have rustup installed (hopefully), so just rustup update and you're good

Lucas Rosa (May 13 2021 at 16:05):

Lucas Rosa (May 13 2021 at 16:06):

Tarjei Skjærset (May 13 2021 at 16:06):

So have you just left your llvm binaries in your Downloads folder? I tried copying them around to where I thought they were supposed to go, but I was doing that blind.

Lucas Rosa (May 13 2021 at 16:08):

Tarjei Skjærset (May 13 2021 at 16:08):

Lucas Rosa (May 13 2021 at 16:08):

and I only bring them into the path when in the roc folder via the llvminit function

Lucas Rosa (May 13 2021 at 16:08):

Lucas Rosa (May 13 2021 at 16:09):

Tarjei Skjærset (May 13 2021 at 16:10):

Lucas Rosa (May 13 2021 at 16:10):

Lucas Rosa (May 13 2021 at 16:11):

Tarjei Skjærset (May 13 2021 at 16:11):

Seems to be compiling fine when I run cargo run repl in regular zsh. Maybe I got tripped up trying to run nix-shell yesterday and thought the llvm binaries weren't working.

Lucas Rosa (May 13 2021 at 16:11):

Tarjei Skjærset (May 13 2021 at 16:12):

It's still going! How long is it supposed to take? Are there incremental builds?

Lucas Rosa (May 13 2021 at 16:13):

fresh one will take a few seconds maybe a minute, not sure what your specs are but the rust compiler is just slower on mac in general from what I noticed

Lucas Rosa (May 13 2021 at 16:13):

Tarjei Skjærset (May 13 2021 at 16:14):

Lucas Rosa (May 13 2021 at 16:14):

Tarjei Skjærset (May 13 2021 at 16:14):

Lucas Rosa (May 13 2021 at 16:14):

Tarjei Skjærset (May 13 2021 at 16:15):

Lucas Rosa (May 13 2021 at 16:15):

just global search the project for Security and comment out that and the line above it

Lucas Rosa (May 13 2021 at 16:15):

it's mostly just for running a single example and won't be there long term anyways

Lucas Rosa (May 13 2021 at 16:16):

Tarjei Skjærset (May 13 2021 at 16:16):

Lucas Rosa (May 13 2021 at 16:16):

Tarjei Skjærset (May 13 2021 at 16:17):

Yeah I found it! I just worried about the thought of doing that every time I pull trunk

Lucas Rosa (May 13 2021 at 16:17):

Tarjei Skjærset (May 13 2021 at 16:17):

Lucas Rosa (May 13 2021 at 16:17):

Tarjei Skjærset (May 13 2021 at 16:19):

Thanks so much for the help! I'll play around for a bit, but I would really love to pair some time :smiley:

Lucas Rosa (May 13 2021 at 16:27):

Richard Feldman (May 13 2021 at 18:44):

yeah, you can see why we're all about the "not ready for a release yet!" in how we talk about Roc publicly :joy:

Richard Feldman (May 13 2021 at 18:44):

long-term goal is that there's a single roc executable to download and that's it - it has the editor, no external libraries to install, etc

Richard Feldman (May 13 2021 at 18:45):

Richard Feldman (May 13 2021 at 18:50):

Chen Yu (Jun 20 2021 at 04:28):

Following https://github.com/rtfeldman/roc/issues/1418, I still get the error using nix installation.

examples/hello-world/hello-world: symbol lookup error: /nix/store/sbbifs2ykc05inws26203h0xwcadnf0l-glibc-2.32-46/lib/libc.so.6: undefined symbol: _dl_fatal_printf, version GLIBC_PRIVATE

:sweat_smile:

Richard Feldman (Jun 20 2021 at 10:53):

Jared Ramirez (Jun 20 2021 at 23:18):

I'm not sure. I just ran cargo run run examples/hello-world/Hello.roc on the latest trunk on macos with everything installed via nix and it worked for me. My guess is that there's a difference on Ubuntu

Richard Feldman (Jun 21 2021 at 02:03):

@Chen Yu one alternate idea is to run the manual instructions in BUILDING_FROM_SOURCE.md - both @Folkert de Vries and I run that setup on Ubuntu without Nix, and it's entirely possible that currently there's nobody else trying to build Roc from Nix on Ubuntu :sweat_smile:

Chen Yu (Jun 21 2021 at 02:09):

Lucas Rosa (Jun 21 2021 at 02:13):

I build from source on fedora without nix using llvmenv to manage multiple llvm versions, feel free to bother me as well

Jan Wirth (Aug 07 2021 at 14:35):

Lucas Rosa (Aug 07 2021 at 14:35):

Folkert de Vries (Aug 07 2021 at 14:35):

Jan Wirth (Aug 07 2021 at 14:36):

Which command would I need to run
I am not very experienced with this lower-level deelopment

Folkert de Vries (Aug 07 2021 at 14:36):

Lucas Rosa (Aug 07 2021 at 14:36):

Lucas Rosa (Aug 07 2021 at 14:37):

Folkert de Vries (Aug 07 2021 at 14:37):

my assumption is that you'd need to get a hold of the LLVM IR (this is not hard, but not exposed in a friendly way) and then convert that to wasm

Jan Wirth (Aug 07 2021 at 14:37):

Folkert de Vries (Aug 07 2021 at 14:37):

but also you'd need to then also compile the host to wasm, and then link stuff together

Folkert de Vries (Aug 07 2021 at 14:37):

Folkert de Vries (Aug 07 2021 at 14:38):

so, yea, it's not easy, might not totally work, but things are in place to make it possible at some point

Jan Wirth (Aug 07 2021 at 14:38):

I see that there is compiler/build/src/target and there is a lot of llvm going on :D

Lucas Rosa (Aug 07 2021 at 14:38):

Lucas Rosa (Aug 07 2021 at 14:39):

Folkert de Vries (Aug 07 2021 at 14:40):

there sure is a lot of llvm going on. Now in theory we could also directly emit wasm bytecode

Folkert de Vries (Aug 07 2021 at 14:40):

Jan Wirth (Aug 07 2021 at 14:40):

I was hoping maybe I can convert the dylib C code to wasm but that seems to not be the right way to go. Again I have next to no experience with compilers. I only compiled my beloved kakoune from source and managed to compile roc now, but I'm more an end-user than a direct user.

Folkert de Vries (Aug 07 2021 at 14:40):

Folkert de Vries (Aug 07 2021 at 14:41):

Jan Wirth (Aug 07 2021 at 14:41):

Folkert de Vries (Aug 07 2021 at 14:41):

not sure what dylib you mean btw, but in general if you have C code and want wasm then I think zig is basicallythe easiest approach

Folkert de Vries (Aug 07 2021 at 14:42):

Folkert de Vries (Aug 07 2021 at 14:43):

Jan Wirth (Aug 07 2021 at 14:45):

I mean the dylib I can compile to with the --lib option. But that's not C code I just saw.

Lucas Rosa (Aug 07 2021 at 14:46):

Lucas Rosa (Aug 07 2021 at 14:47):

Jan Wirth (Aug 07 2021 at 14:48):

Folkert de Vries (Aug 07 2021 at 14:50):

not really, interestingly. It's such a broad topic, and there is a lot of space between "technically working" and what you should do if you write a real production-grade compiler

Folkert de Vries (Aug 07 2021 at 14:51):

but in general, there are 4 big phases: parsing, canonicalization (make sure names are defined and such), type checking, and code generation

Folkert de Vries (Aug 07 2021 at 14:51):

Jan Wirth (Aug 07 2021 at 14:52):

So the gen_wasm is only the last step, right? Are there guides on generator design? Or is it essentially learning how wasm bytecode works and then building a big ol module that outputs it with whatever means necessary?

Richard Feldman (Aug 07 2021 at 14:53):

@Jan Wirth are you interested in working on adding wasm generation support to the Roc compiler? if so, I'd be happy to help via pair programming and such!

Folkert de Vries (Aug 07 2021 at 14:53):

Richard Feldman (Aug 07 2021 at 14:53):

Folkert de Vries (Aug 07 2021 at 14:53):

Richard Feldman (Aug 07 2021 at 14:53):

Folkert de Vries (Aug 07 2021 at 14:53):

Jan Wirth (Aug 07 2021 at 14:54):

I would be very pleased to do that but I would need to carve out some time / energy.

Richard Feldman (Aug 07 2021 at 14:54):

Folkert de Vries (Aug 07 2021 at 14:54):

and yea it's in essence converting our intermediate representation to the right sequence of wasm bytecode instructions

Richard Feldman (Aug 07 2021 at 14:54):

@Jan Wirth cool! No pressure or anything, but feel free to hit me up anytime if you decide you want to dive into it!

Folkert de Vries (Aug 07 2021 at 14:55):

Richard Feldman (Aug 07 2021 at 14:55):

Folkert de Vries (Aug 07 2021 at 14:55):

Jan Wirth (Aug 07 2021 at 14:55):

I go on vacay in a week because I really need it and then I think I can decide if I can take it on and to what extend. I have an elm frontend to ship :)

Richard Feldman (Aug 07 2021 at 14:55):

Folkert de Vries (Aug 07 2021 at 14:55):

so that makes me think maybe taking the LLVM IR we already make and try to turn that into a working wasm app may be an easier starting point

Richard Feldman (Aug 07 2021 at 14:56):

Jan Wirth (Aug 07 2021 at 14:56):

I'm happy and keen to put some stuff on my kindle though, so if you have a nice guide to pair-programming or compilers etc. please share :)

Jan Wirth (Aug 07 2021 at 14:59):

Folkert de Vries (Aug 07 2021 at 15:00):

not very kindle-friendly but I think elm's compiler source code is kind of the best thing to read (if you appreciate haskell, of course)

Richard Feldman (Aug 07 2021 at 15:00):

I was already planning to write some Str docs today, so I'll see about adding some overall compiler docs in there

Jan Wirth (Aug 07 2021 at 15:07):

Folkert de Vries (Aug 07 2021 at 15:10):

Folkert de Vries (Aug 07 2021 at 15:11):

Lucas Rosa (Aug 07 2021 at 15:19):

@Jan Wirth the craftinginterpreters.com book is awesome, new, and beginner friendly. There is a web version available for free

Folkert de Vries (Aug 07 2021 at 15:20):

Lucas Rosa (Aug 07 2021 at 15:22):

so part 2 is a tree walk interpreter and just traverses the AST for evaluation. Part 3 he redoes everything in C, makes a VM, bytecode from AST, and even a GC

Lucas Rosa (Aug 07 2021 at 15:23):

Part 2 is in Java but I’ve been translating it to rust as I go. Part 3 will be in zig for me

Lucas Rosa (Aug 07 2021 at 15:26):

Lucas Rosa (Aug 07 2021 at 15:27):

JT worked on typescript, currently does nushell, and was on the same episode of zig showtime as me :D

Brian Carroll (Oct 10 2021 at 19:42):

I just pulled the latest trunk and cargo build is throwing an error. Looks like a new package got added maybe? Anyone know how to fix it? I'm pretty new to Rust so it's probably something silly.

error: failed to run custom build command for `alsa-sys v0.3.1`

thread 'main' panicked at 'Failed to run `"pkg-config" "--libs" "--cflags" "alsa"`: No such file or directory (os error 2)', /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/alsa-sys-0.3.1/build.rs:13:18

Richard Feldman (Oct 10 2021 at 20:12):

if you're on Linux, the mention of alsa might mean it's related to audio - which we recently introduced to the editor

Richard Feldman (Oct 10 2021 at 20:13):

Richard Feldman (Oct 10 2021 at 20:16):

it looks like the alsa-sys crate is using pkg-config to build something when the crate gets installed, but it's missing something

Richard Feldman (Oct 10 2021 at 20:17):

so maybe you need to have pkg-config installed? (And if so, maybe we need to add that to the building from source instructions)

Brian Carroll (Oct 10 2021 at 22:22):

Anton (Oct 11 2021 at 07:41):

I added pkg-config to building from source. I think I'll make a script to install everything required to build from source starting with Ubuntu/Debian.

Wolfgang Schuster (Oct 11 2021 at 23:41):

> cargo run repl
   Compiling roc_builtins v0.1.0 (/home/wolfadex/Development/roc/compiler/builtins)
   Compiling pulldown-cmark v0.8.0
   Compiling nix v0.17.0
   Compiling dlib v0.5.0
   Compiling ash v0.33.3+1.2.191
   Compiling dlib v0.4.2
   Compiling libc v0.2.101
   Compiling proc-macro2 v1.0.29
error: failed to run custom build command for `roc_builtins v0.1.0 (/home/wolfadex/Development/roc/compiler/builtins)`
Caused by:
  process didn't exit successfully: `/home/wolfadex/Development/roc/target/debug/build/roc_builtins-9e4973e4a864c4ee/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rustc-env=BUILTINS_O=/home/wolfadex/Development/roc/target/debug/build/roc_builtins-00366df05b0327aa/out/builtins.o
  Compiling zig object to: /home/wolfadex/Development/roc/compiler/builtins/bitcode/builtins-host.o

  --- stderr
  thread 'main' panicked at 'zig failed: error: unable to find zig installation directory: FileNotFound
  ', compiler/builtins/build.rs:124:17
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Seems to be something Zig specific. Dug a little and saw that it's trying to do a zig build ... from /compiler/builtins and notice that if I run zig build I get the same error

> zig build
error: unable to find zig installation directory: FileNotFound

Lucas Rosa (Oct 11 2021 at 23:52):

Lucas Rosa (Oct 11 2021 at 23:54):

Wolfgang Schuster (Oct 12 2021 at 00:03):

I don't actually remember because I installed it many, many months ago. I'll try re-installing though, thanks!

Wolfgang Schuster (Oct 12 2021 at 00:44):

Lucas Rosa (Oct 12 2021 at 00:48):

Nathan Kramer (Oct 25 2021 at 10:28):

Hi all, silly question :)
when I run cargo build --release, should I see a roc CLI binary in ./target/release?
I can see roc, but that's the editor right?
I was imagining I would build a binary executable and then add it to my PATH so that I can use roc in any arbitrary directory. :sweat_smile:

Shritesh Bhattarai (Oct 25 2021 at 11:42):

If you use roc without any arguments, it opens the editor. You can also doroc repl, roc FILENAME or roc --help.

Nathan Kramer (Oct 25 2021 at 11:52):

Notification Bot (Oct 25 2021 at 11:52):

Locria Cyber (Oct 27 2021 at 03:49):

> cargo run --release examples/hello-world/Hello.roc
    Finished release [optimized] target(s) in 0.23s
     Running `target/release/roc examples/hello-world/Hello.roc`
fish: Job 1, 'cargo run --release examples/he…' terminated by signal SIGILL (Illegal instruction)

Locria Cyber (Oct 27 2021 at 03:49):

Brendan Hansknecht (Oct 27 2021 at 04:41):

What system are you running on? Also, if you run cargo test, which ones pass/fail?

Locria Cyber (Oct 27 2021 at 06:50):

running 22 tests
test cli_run::effect ... FAILED
test cli_run::closure ... FAILED
test cli_run::cli ... FAILED
test cli_run::hello_web ... ok
test cli_run::fib ... FAILED
test cli_run::cfold ... FAILED
test cli_run::hello_rust ... FAILED
test cli_run::astar ... FAILED
test cli_run::quicksort_app ... ok
test cli_run::hello_world ... FAILED
test cli_run::hello_zig ... FAILED
test cli_run::quicksort ... FAILED
test cli_run::run_multi_dep_str_optimized ... FAILED
test cli_run::nqueens ... FAILED
test cli_run::base64 ... FAILED
test cli_run::rbtree_insert ... FAILED
test cli_run::rbtree_ck ... FAILED
test cli_run::run_multi_dep_str_unoptimized ... FAILED
test cli_run::run_multi_dep_thunk_optimized ... FAILED
test cli_run::run_multi_dep_thunk_unoptimized ... FAILED
test cli_run::deriv ... FAILED
test cli_run::false_interpreter ... FAILED

Locria Cyber (Oct 27 2021 at 06:51):

Folkert de Vries (Oct 27 2021 at 07:23):

Locria Cyber (Oct 27 2021 at 07:28):

Folkert de Vries (Oct 27 2021 at 07:38):

interesting. does cargo run -- build --release examples/hello-world/Hello.roc work?

Folkert de Vries (Oct 27 2021 at 07:38):

Locria Cyber (Oct 27 2021 at 07:43):

Locria Cyber (Oct 27 2021 at 07:44):

Thread 1 "roc" received signal SIGILL, Illegal instruction.
<some location> in llvm::getTimeTraceProfilerInstance() ()

Locria Cyber (Oct 27 2021 at 07:45):

Folkert de Vries (Oct 27 2021 at 07:47):

Locria Cyber (Oct 27 2021 at 07:55):

Locria Cyber (Oct 27 2021 at 07:56):

Folkert de Vries (Oct 27 2021 at 07:57):

Folkert de Vries (Oct 27 2021 at 07:58):

Locria Cyber (Oct 27 2021 at 08:25):

Anton (Oct 27 2021 at 13:07):

@Locria Cyber if you want to try running roc, there is a nightly release available from a couple of days ago here. If you want to change any source code there is a developer_install.sh script(Debian/Ubuntu) that I still need to double check but should work as is. I also made you a docker container, I'll post a link when it is finished uploading. If you want to use nix, make sure to apply matthiasbeyer's fix, see PR #1831.

Anton (Oct 27 2021 at 13:13):

Oliver Schöning (Oct 27 2021 at 14:06):

@Anton omg I did not know this was an option to use roc like that without all the install steps!

Anton (Oct 27 2021 at 15:06):

It's a very recent addition :) I was planning on adding it to the docs once the release runs automatically every night, which should be soon.

Oliver Schöning (Oct 27 2021 at 15:13):

@Anton speaking of docs. If I want to see the docs do I need to run cargo run docs ?
Coz I tried that and got this on the latest master branch:

oliverschoning@pop-os:~/Projects/roc$ cargo run docs
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s
     Running `target/debug/roc docs`
── FILE NOT FOUND ──────────────────────────────────────────────────────────────

I am looking for this file, but it's not there:

    ./compiler/load/tests/fixtures/build/no_deps/ThisFileIsMissing.roc

Is the file supposed to be there? Maybe there is a typo in the file
name?
thread 'main' panicked at 'explicit panic', docs/src/lib.rs:436:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Oliver Schöning (Oct 27 2021 at 15:16):

I dunno what "Docs" entails tbh. So far I am just looking at the examples folder and trying to see if I can manage to build something myself :big_smile:

Anton (Oct 27 2021 at 15:27):

With docs I was referring to the repo README.
I suppose for making or changing examples, it is best to use these resources:

Oliver Schöning (Oct 27 2021 at 15:28):

Anton (Oct 27 2021 at 15:29):

cargo run docs generates documentation for roc files/projects, we're still working on docs syntax highlighting so I'm not sure how much the cargo run docs command does yet.

Oliver Schöning (Oct 27 2021 at 15:30):

Locria Cyber (Oct 27 2021 at 22:31):

Brendan Hansknecht (Oct 28 2021 at 00:10):

Logan Lowder (Oct 29 2021 at 21:44):

I'm trying to build from source on macOS Big Sur (11.6) and getting an error about llvm:

I installed llvm with brew install llvm@12 and then added /usr/local/opt/llvm/bin to my path, but noticed that no path by that name exists on my system, but /usr/local/opt/llvm@12/bin does, so I added that to my path and afterwards running llc --version generates output starting with Homebrew LLVM version 12.0.1 as BUILDING_FROM_SOURCE.md mentions.

cargo run repl
   Compiling llvm-sys v120.2.1
   Compiling snafu v0.6.10
   Compiling parking_lot_core v0.8.5
   Compiling wasmer-vm v2.0.0
   Compiling wasmer-wasi-types v2.0.0
   Compiling cranelift-frontend v0.74.0
   Compiling rodio v0.14.0
error: No suitable version of LLVM was found system-wide or pointed
       to by LLVM_SYS_120_PREFIX.

       Consider using `llvmenv` to compile an appropriate copy of LLVM, and
       refer to the llvm-sys documentation for more information.

       llvm-sys: https://crates.io/crates/llvm-sys
       llvmenv: https://crates.io/crates/llvmenv
   --> /Users/llowder/.cargo/registry/src/github.com-1ecc6299db9ec823/llvm-sys-120.2.1/src/lib.rs:486:1
    |
486 | / std::compile_error!(concat!(
487 | |     "No suitable version of LLVM was found system-wide or pointed
488 | |        to by LLVM_SYS_",
489 | |     env!("CARGO_PKG_VERSION_MAJOR"),
...   |
496 | |        llvmenv: https://crates.io/crates/llvmenv"
497 | | ));
    | |___^

error: could not compile `llvm-sys` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

Logan Lowder (Oct 29 2021 at 21:52):

Folkert de Vries (Oct 29 2021 at 21:53):

set -x LLVM_SYS_120_PREFIX "/home/folkertdev/Downloads/clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04"

Folkert de Vries (Oct 29 2021 at 21:54):

Logan Lowder (Oct 29 2021 at 22:04):

Logan Lowder (Oct 29 2021 at 22:06):

Richard Feldman (Oct 29 2021 at 22:07):

Logan Lowder (Oct 29 2021 at 22:07):

Logan Lowder (Oct 29 2021 at 22:09):

I think I was over thinking it! export LLVM_SYS_120_PREFIX=/usr/local/opt/llvm@12 seems to make it happier

Logan Lowder (Oct 29 2021 at 22:10):

I was thinking the prefix was supposed to be a specific executable rather than the dir where llvm lives

Logan Lowder (Oct 29 2021 at 22:10):

Logan Lowder (Oct 29 2021 at 22:11):

Richard Feldman (Oct 29 2021 at 22:16):

Logan Lowder (Oct 30 2021 at 18:24):

Locria Cyber (Oct 31 2021 at 06:03):

thread 'main' panicked at 'Request adapter', editor/src/editor/main.rs:82:14

Locria Cyber (Oct 31 2021 at 06:03):

    let (gpu_device, cmd_queue) = futures::executor::block_on(async {
        let adapter = instance
            .request_adapter(&wgpu::RequestAdapterOptions {
                power_preference: wgpu::PowerPreference::HighPerformance,
                compatible_surface: Some(&surface),
            })
            .await
            .expect("Request adapter");

Locria Cyber (Oct 31 2021 at 06:06):

[nix-shell:~/computing/roc]$ glxgears
glxgears: symbol lookup error: /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libdl.so.2: undefined symbol: _dl_catch_error_ptr, version GLIBC_PRIVATE

[nix-shell:~/computing/roc]$ vulkaninfo
ERROR: [Loader Message] Code 0 : libdrm.so.2: cannot open shared object file: No such file or directory
ERROR: [Loader Message] Code 0 : libLLVM-12.so: cannot open shared object file: No such file or directory
ERROR: [Loader Message] Code 0 : libGLX_nvidia.so.0: cannot open shared object file: No such file or directory
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
ERROR at /build/source/vulkaninfo/vulkaninfo.h:687:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER

[nix-shell:~/computing/roc]$ which vulkaninfo
/nix/store/9bn3gwiw64bdxi7k9a2h39974c39cs89-vulkan-tools-1.2.189.1/bin/vulkaninfo

Locria Cyber (Oct 31 2021 at 06:06):

Locria Cyber (Oct 31 2021 at 06:21):

Locria Cyber (Oct 31 2021 at 06:35):

Installed nixGL, and now another library panics. I think I'll not use roc-editor then.

Anton (Oct 31 2021 at 11:18):

Hi Locria, sorry about this, it sounds very frustrating.
The roc editor is still a WIP and not ready yet to replace your favorite editor, I'll make sure to mention this in the BUILDING_FROM_SOURCE file.
The editor installation process will be much improved in the near future.
I was able to reproduce this error locally and will look at it soon.

Anton (Oct 31 2021 at 13:27):

# outside of nix shell:
nix-channel --add https://github.com/guibou/nixGL/archive/main.tar.gz nixgl && nix-channel --update
nix-env -iA nixgl.auto.nixVulkanNvidia
# does not work with nix-shell --pure
nix-shell
# 460.91.03 may be different for you, type nixVulkanNvidia and press tab to autocomplete for your version
nixVulkanNvidia-460.91.03 cargo run edit

Anton (Oct 31 2021 at 15:02):

Kevin Hovsäter (Nov 03 2021 at 11:42):

I've had no problems in running the tests while writing builtins, but I just tried the REPL on macOS and it just fail upon evaluating any Roc code. Seems like it can't find a given dylib. Any ideas?

Kevin Hovsäter (Nov 03 2021 at 11:49):

Hmm something else must be going on. All tests are failing since I updated my branch with latest trunk.

Kevin Hovsäter (Nov 03 2021 at 11:49):

Kevin Hovsäter (Nov 03 2021 at 12:01):

Problems averted. Turns out I had to upgrade my CLT since upgrading to macOS Monterey. All good now. :smile:

Kevin Hovsäter (Nov 03 2021 at 12:12):

Looks like I get a failing test case though when running cargo test. This is on macOS 12.0.1, running Rust 1.56.0 and Zig 0.8.1.

Kevin Hovsäter (Nov 03 2021 at 12:40):

Rerunning the tests using cargo test -p test_gen --lib gave me the following error:

Kevin Hovsäter (Nov 03 2021 at 12:44):

Rerunning the tests inside of lldb breaks on gen_primitives::lambda_set_enum_byte_byte, but running the test in isolation doesn't cause any issues.

Kevin Hovsäter (Nov 03 2021 at 12:46):

I've never used tools such as gdb, lldb and valgrind, so I'm not really sure how to debug this. I'd love to pair on it if someone wants to.

Kevin Hovsäter (Nov 03 2021 at 16:17):

Not sure if this helps or not, but running cargo test --release -p test_gen --lib also cause the same issue. So it's persistent in both debug and release builds.

Folkert de Vries (Nov 03 2021 at 16:18):

Folkert de Vries (Nov 03 2021 at 16:32):

and for you to follow along, I put the test into its own file (I pick examples/benchmarks/Scratchpad.roc for this

app "scratchpad"
     packages { base: "platform" }
     imports [base.Task]
     provides [ main ] to base


main : Task.Task {} []
main =
    r : [ Red, Green, Blue ]
    r = Red

    g : [ Red, Green, Blue ]
    g = Green

    p1 = (\u -> r == u)
    p2 = (\u -> g == u)
    oneOfResult = List.map [p1, p2] (\p -> p Green)

    when List.len oneOfResult is
        n -> Task.putLine (Str.fromInt n)

Now we can compile this. I use the --debug flag, which will give extra info like line numbers. It requires you install debugir. If you haven't, just run this and the error message will point you to where to get it from:

cargo run -- --debug examples/benchmarks/Scratchpad.roc

valgrind --leak-check=full --track-origins=yes ./scratchpad

==346834== Memcheck, a memory error detector
==346834== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==346834== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==346834== Command: ./scratchpad
==346834== 
==346834== Invalid write of size 8
==346834==    at 0x152714: ??? (Scratchpad.ll:1665)
==346834==    by 0x152628: roc__mainForHost_1_exposed_generic (Scratchpad.ll:1593)
==346834==    by 0x1112A0: main (host.zig:103)
==346834==  Address 0x4c05060 is 6 bytes after a block of size 26 alloc'd
==346834==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==346834==    by 0x110D57: roc_alloc (host.zig:48)
==346834==    by 0x1526F2: ??? (Scratchpad.ll:1651)
==346834==    by 0x152628: roc__mainForHost_1_exposed_generic (Scratchpad.ll:1593)
==346834==    by 0x1112A0: main (host.zig:103)
==346834== 
==346834== Invalid read of size 8
==346834==    at 0x152850: ??? (Scratchpad.ll:1764)
==346834==    by 0x152725: ??? (Scratchpad.ll:1668)
==346834==    by 0x152628: roc__mainForHost_1_exposed_generic (Scratchpad.ll:1593)
==346834==    by 0x1112A0: main (host.zig:103)
==346834==  Address 0x4c05059 is 25 bytes inside a block of size 26 alloc'd
==346834==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==346834==    by 0x110D57: roc_alloc (host.zig:48)
==346834==    by 0x1526F2: ??? (Scratchpad.ll:1651)
==346834==    by 0x152628: roc__mainForHost_1_exposed_generic (Scratchpad.ll:1593)
==346834==    by 0x1112A0: main (host.zig:103)
==346834== 
==346834== Conditional jump or move depends on uninitialised value(s)
==346834==    at 0x152766: ??? (Scratchpad.ll:1681)
==346834==    by 0x15285A: ??? (Scratchpad.ll:1765)
==346834==    by 0x152725: ??? (Scratchpad.ll:1668)
==346834==    by 0x152628: roc__mainForHost_1_exposed_generic (Scratchpad.ll:1593)
==346834==    by 0x1112A0: main (host.zig:103)
==346834==  Uninitialised value was created by a heap allocation
==346834==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==346834==    by 0x110D57: roc_alloc (host.zig:48)
==346834==    by 0x1526F2: ??? (Scratchpad.ll:1651)
==346834==    by 0x152628: roc__mainForHost_1_exposed_generic (Scratchpad.ll:1593)
==346834==    by 0x1112A0: main (host.zig:103)
==346834== 
2
runtime: 17.481ms
==346834== 
==346834== HEAP SUMMARY:
==346834==     in use at exit: 0 bytes in 0 blocks
==346834==   total heap usage: 2 allocs, 2 frees, 36 bytes allocated
==346834== 
==346834== All heap blocks were freed -- no leaks are possible
==346834== 
==346834== For lists of detected and suppressed errors, rerun with: -s
==346834== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

That --debug flag also make sure the LLVM IR is written to Scratchpad.ll, so we can inspect it. Usually it makes most sense to work from the top error downward. In this case, that line points us to this LLVM IR

%roc_alloc = tail call i8* @roc_alloc(i64 26, i32 1)
...
%.repack22 = getelementptr inbounds i8, i8* %roc_alloc, i64 32

where we allocate something that is 26 bytes, but then get a pointer to its 32th byte. That's an out of bounds access, and definitely a bug

Brendan Hansknecht (Nov 03 2021 at 16:34):

If your ever interested in learning more about these tools, I am willing to pair. Just DM me. I have used them quite a bit, especially since I tend to deal with low level stuff within roc.

Kevin Hovsäter (Nov 03 2021 at 16:43):

This was super helpful! How did you know which test to use? To me it looked like it was failing randomly on different test cases.

Folkert de Vries (Nov 03 2021 at 16:44):

this was the one that you said failed. I'd usually use lldb to find out where the segfault happens

Kevin Hovsäter (Nov 03 2021 at 16:48):

Folkert de Vries (Nov 03 2021 at 16:50):

I'm looking at it, you can give it a go too. My theory is that we're allocating too little memory here, likely not taking alignment into account

Folkert de Vries (Nov 03 2021 at 16:58):

Folkert de Vries (Nov 03 2021 at 17:23):

Kevin Hovsäter (Nov 03 2021 at 17:26):

Sure. I’ll try it out. Really impressed with your debugging skills. Would love to know more about how you ended up finding where the problem was. 🙂

Kevin Hovsäter (Nov 03 2021 at 17:57):

@Folkert de Vries seems to have fixed it! Get another failure, but I think it's unrelated. It's the hello_swift one.

Richard Feldman (Nov 03 2021 at 18:09):

test gen_tags::false_is_false ... ok
test gen_tags::applied_tag_just_enum ... ok
test gen_tags::alignment_in_multi_tag_construction_two ... ok
test_gen-ef19d83dce25afb6(25024,0x700007630000) malloc: *** error for object 0x7fee1a1705d0: pointer being freed was not allocated
test_gen-ef19d83dce25afb6(25024,0x700007630000) malloc: *** set a breakpoint in malloc_error_break to debug

Kevin Hovsäter (Nov 03 2021 at 18:16):

I'm also on x64. I had a failure initially, but after running cargo clean and then cargo test they all seem to pass consistently.

Richard Feldman (Nov 03 2021 at 18:24):

interesting - I ran cargo clean and now hello_swift is failing, but gen_tags is still failing :laughing:

Richard Feldman (Nov 03 2021 at 18:24):

$ cargo test --lib gen_tags

running 54 tests
test gen_tags::applied_tag_just_enum ... ok
test gen_tags::alignment_in_multi_tag_construction_two ... ok
test gen_tags::applied_tag_just_ir ... ok
test gen_tags::applied_tag_just ... ok
error: test failed, to rerun pass '-p test_gen --lib'

Caused by:
  process didn't exit successfully: `/Users/rtfeldman/code/roc/target/debug/deps/test_gen-ef19d83dce25afb6 gen_tags` (signal: 11, SIGSEGV: invalid memory reference)

Folkert de Vries (Nov 03 2021 at 18:25):

can you runlldb /Users/rtfeldman/code/roc/target/debug/deps/test_gen-ef19d83dce25afb6 -- gen_tags

Folkert de Vries (Nov 03 2021 at 18:25):

that opens up a repl thing, then run run and then bt and that should show you which test case is responsible

Richard Feldman (Nov 03 2021 at 18:26):

running 54 tests
test gen_tags::applied_tag_just ... ok
test gen_tags::applied_tag_just_ir ... ok
test_gen-ef19d83dce25afb6(28983,0x700007235000) malloc: *** error for object 0x113057d00: pointer being freed was not allocated
test_gen-ef19d83dce25afb6(28983,0x700007235000) malloc: *** set a breakpoint in malloc_error_break to debug
Process 28983 stopped
* thread #9, name = 'gen_tags::applied_tag_function_result', stop reason = signal SIGABRT
    frame #0: 0x00007fff202e492e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff202e492e <+10>: jae    0x7fff202e4938            ; <+20>
    0x7fff202e4930 <+12>: movq   %rax, %rdi
    0x7fff202e4933 <+15>: jmp    0x7fff202dead9            ; cerror_nocancel
    0x7fff202e4938 <+20>: retq

Folkert de Vries (Nov 03 2021 at 18:29):

Richard Feldman (Nov 03 2021 at 18:30):

Richard Feldman (Nov 03 2021 at 18:31):

Folkert de Vries (Nov 03 2021 at 21:07):

@Richard Feldman do you remember when this worked last? because I think we're hitting a more fundamental problem with our RC insertion here

Folkert de Vries (Nov 03 2021 at 21:08):

Richard Feldman (Nov 03 2021 at 21:10):

Richard Feldman (Nov 03 2021 at 21:49):

Lucas Rosa (Nov 03 2021 at 21:57):

Lucas Rosa (Nov 03 2021 at 21:58):

Folkert de Vries (Nov 03 2021 at 22:03):

hmm well maybe it does not crash but it still gives valgrind errors before that commit

Richard Feldman (Nov 03 2021 at 23:17):

does it still give valgrind errors even if you cherry-pick the fix from the branch? :thinking:

Locria Cyber (Nov 04 2021 at 05:59):

Brendan Hansknecht (Nov 04 2021 at 06:04):

What specifically is causing an issue for that? I have had roc running on arch before.

Brendan Hansknecht (Nov 04 2021 at 06:05):

Is it specifically an issue of needing software from the aur or something different like versioning issues?

Locria Cyber (Nov 04 2021 at 06:08):

Brendan Hansknecht (Nov 04 2021 at 06:10):

Kevin Hovsäter (Nov 04 2021 at 08:34):

Anton (Nov 04 2021 at 08:59):

Folkert de Vries (Nov 04 2021 at 09:56):

What we do is we infer a borrow signature first for List.map (or any lowlevel that takes a function argument), and only later for the function that we pass in practice. That means in this case that List.map thinks that the passed function borrows the element, while in practice it owns it.

Folkert de Vries (Nov 04 2021 at 09:57):

Richard Feldman (Nov 04 2021 at 11:10):

Kevin Hovsäter (Nov 04 2021 at 11:21):

Lucas Rosa (Nov 04 2021 at 13:23):

Lucas Rosa (Nov 04 2021 at 13:26):

Lucas Rosa (Nov 04 2021 at 13:28):

ok this is good enough for me to start getting some work done, I'll sort out why I have failing tests later

Lucas Rosa (Nov 04 2021 at 13:29):

Lucas Rosa (Nov 04 2021 at 13:32):

Lucas Rosa (Nov 04 2021 at 13:35):

rm -rf target

time cargo test -p test_gen gen_dict

223.99s user 18.11s system 549% cpu 44.097 total

Lucas Rosa (Nov 04 2021 at 13:36):

Folkert de Vries (Nov 04 2021 at 13:37):

Lucas Rosa (Nov 04 2021 at 13:37):

Lucas Rosa (Nov 04 2021 at 13:38):

although 223s is still pretty fast considering it had to compile most of the crates before running the tests

Folkert de Vries (Nov 04 2021 at 13:41):

Oleksii Skidan (Nov 04 2021 at 13:45):

Is there a guide somewhere about how to enable M1 support? Mabye a specific branch?

Lucas Rosa (Nov 04 2021 at 13:47):

I didn't really do much outside of brew install llvm@12, but I've only ran a few tests and the repl which is usually enough for me to get some work done. What command did you run or what code did you try that is giving you trouble?

Oleksii Skidan (Nov 04 2021 at 20:45):

I finally nailed it. Roc builds and runs on my MacBook Pro just fine. :tada:
According to CONTRIBUTING.md I have to talk to an existing contributor about the pull request that I want to make. Who shall I talk to?

Oleksii Skidan (Nov 04 2021 at 20:48):

A bit of a problem as well for me, my Mac is running low on disk space (30GB left out of 256GB). There's nothing I can do to clean up some space. That guide is telling me to run tests in Earthly prior to making a PR. Unfortunately, I won't be able to run them now. :( Not until I have access to my home PC where I can run Linux. The fun part is that Earthly won't exercise any of the macOS-specific stuff then as far as I can tell, will it?

Shritesh Bhattarai (Nov 04 2021 at 20:49):

Brendan Hansknecht (Nov 04 2021 at 20:55):

I wouldn't worry about earthly. It is what CI runs and is nice if you really want to make sure a pr is good, but doesn't matter a ton for local testing.

Brendan Hansknecht (Nov 04 2021 at 20:55):

Brendan Hansknecht (Nov 04 2021 at 20:57):

The main thing about talking to existing contributors is probably for if you are going to make larger changes. Don't want to waste effort when multiple people work on the same thing or someone adds features in a way that fundamentally Roc doesn't want. But for bug fixes and getting the programming working on a new system, just opening a PR should be great.

Oleksii Skidan (Nov 04 2021 at 21:05):

OK, what's the procedure then? Shall I push a new branch with the fix, if so is there any specific format for how to name it?

Folkert de Vries (Nov 04 2021 at 21:07):

yes make a branch. There is no naming format, pick something descriptive and you should be good

Oleksii Skidan (Nov 04 2021 at 21:25):

Johannes Hoff (Dec 01 2021 at 21:04):

Trying Roc for the first time (for advent of code; not sure I should post there instead), but getting this while trying cargo build:

  thread 'main' panicked at 'zig failed: error: AccessDenied
  ', compiler/builtins/build.rs:150:17

Lucas Rosa (Dec 01 2021 at 21:05):

Lucas Rosa (Dec 01 2021 at 21:06):

Johannes Hoff (Dec 01 2021 at 21:06):

I managed to build and run hello world in zig, so at least the installation isn't completely broken

Brendan Hansknecht (Dec 01 2021 at 21:12):

Folkert de Vries (Dec 01 2021 at 21:12):

Folkert de Vries (Dec 01 2021 at 21:13):

Johannes Hoff (Dec 01 2021 at 21:18):

I'm on MacOS/aarch64. I'm running cargo build from the project root (i.e. the folder with .git)

Brendan Hansknecht (Dec 01 2021 at 21:18):

Johannes Hoff (Dec 01 2021 at 21:20):

Folkert de Vries (Dec 01 2021 at 21:21):

Brendan Hansknecht (Dec 01 2021 at 21:22):

Otherwise, it is possible an issue with cache dir resolution for some reason, like is mentioned here: https://github.com/ziglang/zig/issues/6810
Though, not nix specific as in the linked issue

Johannes Hoff (Dec 01 2021 at 21:25):

Oh, I see what the problem is. I totally created this problem myself. Had copied something from another user and had to chown it. Sorry for the trouble; should have caught it myself

Lucas Rosa (Dec 01 2021 at 21:26):

Taylor Allred (Dec 10 2021 at 22:04):

error: failed to run custom build command for `roc_builtins v0.1.0 (C:\Users\taylo\Documents\Projects\roc\compiler\builtins)`

Caused by:
  process didn't exit successfully: `C:\Users\path\to\roc\target\debug\build\roc_builtins-f32964a2162d4b2f\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  Compiling host ir to: \\?\C:\Users\path\to\roc\compiler\builtins\bitcode\builtins-host.ll

  --- stderr
  thread 'main' panicked at 'zig failed:
  Unhandled Exception: System.ArgumentException: Illegal characters in path.
     at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
     at System.IO.Directory.InternalGetCurrentDirectory(Boolean checkHost)
     at shim.ShimProgram.Main(String[] args)
  ', compiler\builtins\build.rs:150:17
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Anton (Dec 11 2021 at 09:20):

Hi @Taylor Allred,
I notice the C:\ in your path, are you using windows or perhaps the Windows Subsystem for Linux?

Luuk de Gram (Dec 12 2021 at 11:10):

Hi all! Is there a way to specify the install path of Zig?
I mainly develop using Zig so the one installed in my $PATH is the master version.
So in short, I'd like to overwrite what's in my $PATH and specify the installation directory of zig 0.8.0 when building the Roc compiler from source.

Anton (Dec 12 2021 at 11:45):

Hi Luuk,
I've made issue #2189 to provide a nice solution for this, until that is done you can either:

Luuk de Gram (Dec 12 2021 at 11:55):

Thanks Anton!
As all I have to do is test some changes, I'll just use option 2 for now :)
(Also thank you for making the issue).

Lucas Rosa (Dec 12 2021 at 19:02):

Yonatan Reicher (Feb 13 2022 at 13:34):

Hi! I'm trying to build roc rn for the first time.
I just installed zig, and when I'm running cargo build I get the following error:

error: failed to run custom build command for `roc_builtins v0.1.0 (G:\Projects\roc\compiler\builtins)`

Caused by:
  process didn't exit successfully: `G:\Projects\roc\target\debug\build\roc_builtins-4fc5c156ddb0b51a\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  Compiling host ir to: \\?\G:\Projects\roc\compiler\builtins\bitcode\builtins-host.ll

  --- stderr
  thread 'main' panicked at 'zig failed:
  Unhandled Exception: System.ArgumentException: Illegal characters in path.
     at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
     at System.IO.Directory.InternalGetCurrentDirectory(Boolean checkHost)
     at shim.ShimProgram.Main(String[] args)
  ', compiler\builtins\build.rs:157:17
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I am on windows.
My windows user does have hebrew characters, but I don't know what it could be trying to access under user.
Maybe somebody knows what's up?

jan kili (Feb 13 2022 at 13:45):

What version of Zig did you install? I believe Roc requires Zig ~~v0.8.0~~ v0.8.1
I'm on macOS using Nix, so all I know about Roc+Windows is this warning

jan kili (Feb 13 2022 at 13:49):

I'm not the right one to help you with this, but for more info on Roc's dependencies you could skim this and these

Yonatan Reicher (Feb 13 2022 at 13:53):

Thank you for responding, I downloaded zig 0.9, should I get 0.8.1?
I think I saw in another thread that you can build on windows but linking wont work

jan kili (Feb 13 2022 at 13:58):

Yonatan Reicher (Feb 13 2022 at 14:01):

Taylor Allred (Mar 11 2022 at 20:26):

Hi @Anton. Sorry for not responding way back when. I believe I was running on windows not in WSL. I'll try this again in both and see how it goes.

Notification Bot (Mar 12 2022 at 08:07):

Anton (Mar 12 2022 at 08:09):

@Taylor Allred we did get building on windows working but running roc programs will not work because linking on windows still has to be implemented. Using WSL should work though.

Jake (Mar 26 2022 at 02:40):

Hi! I'm trying to build from source on an aarch64 Debian GNU/Linux system, using the latest in the trunk. I get the following error during the cargo build

$ cargo build
   Compiling roc_linker v0.1.0 (/path-to/roc/linker)
error[E0308]: mismatched types
   --> linker/src/lib.rs:676:40
    |
676 |             let c_buf: *const c_char = dynstr_data[dynstr_off..].as_ptr() as *const i8;
    |                        -------------   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
    |                        |
    |                        expected due to this
    |
    = note: expected raw pointer `*const u8`
               found raw pointer `*const i8`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `roc_linker` due to previous error

I can get the build to succeed by changing from i8 to c_char, as hinted by the error, but I'm not sure the implications of that... Has anybody encountered this before? I'm brand new to all of this but trying to learn :smile:

Jake (Mar 26 2022 at 02:45):

even after getting past that error with that naive change, I cannot get many of the cli_run tests to pass. Lots of this error

---- cli_run::cfold stdout ----
thread 'cli_run::cfold' panicked at 'roc build had stderr: thread '<unnamed>' panicked at 'Failed to rebuild host.zig - stderr of the `zig` command was:
error: UnknownOperatingSystem
', compiler/build/src/link.rs:1111:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', cli/src/build.rs:233:50
', cli/tests/cli_run.rs:87:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Ayaz Hafiz (Mar 26 2022 at 02:46):

Brendan Hansknecht (Mar 26 2022 at 02:49):

The first change looks to be a bug on our part. No matter the rust version, we should be converting that to a c_char instead of the exact numeric type. That should be a safe change.

Ayaz Hafiz (Mar 26 2022 at 02:49):

Regarding the second, are you able to run “zig build” in examples/hello-world/zig-platform? the error message indicates it may be a zig problem

Ayaz Hafiz (Mar 26 2022 at 02:51):

Jake (Mar 26 2022 at 02:52):

Jake (Mar 26 2022 at 02:55):

I'm happy to open a PR for the first issue once I can get all my test failures fixed.

@Ayaz Hafiz I was able to get a successful zig build in that directory you mentioned. I had to zig init-exe first though? Sorry, I'm brand new to Rust, Zig, Roc, the works :smile: . I appreciate the help!

Jake (Mar 26 2022 at 03:05):

$ cargo run examples/hello-world/zig-platform/helloZig.roc

I'll take another look through the docs to make sure I didn't miss something in all the installation steps

Ayaz Hafiz (Mar 26 2022 at 03:08):

sorry, i have to hop off to work but i will try to take a deeper look tomorrow morning if you or another helpful friend are unable to resolve this by then!

Jake (Mar 26 2022 at 03:09):

no worries! I appreciate the help so far and will try to do my best to figure it out in the meantime

Brendan Hansknecht (Mar 26 2022 at 03:22):

So zig biuld was actually the wrong command here. We manually build the host with a more complex form of zig build-obj with a solid number of flags

Brendan Hansknecht (Mar 26 2022 at 03:23):

To start simpler and check if the compiler is working in general, can you try:
cargo run examples/hello-world/rust-platform/helloRust.roc

Brendan Hansknecht (Mar 26 2022 at 03:24):

Jake (Mar 26 2022 at 03:29):

Yes, this works fine! I was testing that and several other examples that are using Rust platforms and they seem fine.

Brendan Hansknecht (Mar 26 2022 at 03:31):

Good to know. So definitely a zig related issue. Can you try and run a zig hello world program on your computer, unrelated to roc.

Brendan Hansknecht (Mar 26 2022 at 03:32):

mkdir hello-world
cd hello-world
zig init-exe
zig build run

Jake (Mar 26 2022 at 03:34):

Richard Feldman (Mar 26 2022 at 03:52):

Jake (Mar 26 2022 at 03:57):

Brendan Hansknecht (Mar 26 2022 at 03:59):

Brendan Hansknecht (Mar 26 2022 at 04:02):

Side note, good change that commenting out that line and the line above it will fix the issue.

Jake (Mar 26 2022 at 04:06):

[compiler/build/src/link.rs:131] target = "aarch64-unknown-linux-gnu"

Jake (Mar 26 2022 at 04:09):

yes, commenting out those two lines did allow me to successfully run the helloZig.roc file!

Brendan Hansknecht (Mar 26 2022 at 04:14):

Brendan Hansknecht (Mar 26 2022 at 04:15):

Jake (Mar 26 2022 at 04:33):

Jake (Mar 26 2022 at 04:36):

Jake (Mar 26 2022 at 04:53):

yes, confirmed that hardcoding aarch64-linux-gnu as the target lets me run the zig platform example locally. Seems like there's some synchronization that needs to be done with the target_triple_str function and how it relates to the zig -target mappings

Brendan Hansknecht (Mar 26 2022 at 04:54):

The unknown should be part of the triple. It is the vendor. So on Macos it is apple.

Brendan Hansknecht (Mar 26 2022 at 04:55):

Maybe zig just removed it cause it generally isn't useful even if it is part of the triple

Jake (Mar 26 2022 at 05:06):

Jake (Mar 26 2022 at 05:10):

the zig wiki also mentions some about how these targets are updated in that repo

Brendan Hansknecht (Mar 26 2022 at 05:32):

Brendan Hansknecht (Mar 26 2022 at 05:34):

Feel free to add a special exceptions. Probably add a comment with a link to the issue.

Jake (Mar 26 2022 at 05:36):

Okay. I've gotta go for the night but am happy to work on this later this weekend

Jake (Mar 26 2022 at 05:36):

Brendan Hansknecht (Mar 26 2022 at 05:36):

Jurek Breuninger (Mar 26 2022 at 11:57):

@Anton Hi, I ran into the same issue you did with nixGL. nixVulkanIntel cannot be installed from nix-channel. But when I clone the repo and try nix-env -f ./ -iA nixgl.auto.nixVulkanIntel I still get error: attribute 'nixgl' in selection path 'nixgl.auto.nixVulkanIntel' not found. What did you do? (or anybody else that got nixVulkanIntel to work)

Brendan Hansknecht (Mar 26 2022 at 14:30):

Brendan Hansknecht (Mar 26 2022 at 14:42):

If actual nix os, I know their is s nix flakes PR rn due to it running into some bugs. Not sure if it is the solution though.

Brendan Hansknecht (Mar 26 2022 at 14:43):

Anton (Mar 26 2022 at 18:10):

Jurek Breuninger (Mar 26 2022 at 19:06):

Jake (Mar 27 2022 at 21:06):

I've opened a PR for my GNU/Linux + ARM build issues, though I still have a few tests which I have not been able to have succeed on my system (more details in the PR)
https://github.com/rtfeldman/roc/pull/2774
I'm just feeling my way through all of this so happy to have suggestions

Brendan Hansknecht (Mar 27 2022 at 21:20):

Oh, extra note, some tests may not pass without much more work. I know that on M1 we have some bugs. Might affect you too.

Folkert de Vries (Mar 27 2022 at 21:29):

gui is very slow to build, so it may just need a bit longer (it can take, idk maybe up to 5/10 min the first time)

Folkert de Vries (Mar 27 2022 at 21:29):

for astar it would be interesting to see the valgrind output, that is valgrind valgrind --leak-check=full --track-origins=yes ./test-astar in the examples/benchmarks folder

Anton (Mar 29 2022 at 13:38):

@Jurek Breuninger I created an issue on the nixGL repo, resolving that should make it easy to fix things for your case.

Jake (Mar 31 2022 at 02:13):

you were right, it just took a while to build. However, I still can't run it successfully. I'll share the output here in case it help, but I haven't spent any time digging into it yet:

---- cli_run::gui stdout ----
thread 'cli_run::gui' panicked at 'roc build had stderr: ld: /home/jake/roc/examples/gui/platform/host.o:(.data..L_MergedGlobals+0x18): undefined reference to `__dso_handle'
ld: /usr/lib/aarch64-linux-gnu/libc_nonshared.a(pthread_atfork.oS): in function `__pthread_atfork':
(.text+0x0): undefined reference to `__dso_handle'
ld: (.text+0x4): undefined reference to `__dso_handle'
ld: /home/jake/roc/examples/gui/hello-gui: hidden symbol `__dso_handle' isn't defined
ld: final link failed: bad value
', cli/tests/cli_run.rs:87:13

Jake (Mar 31 2022 at 02:15):

Nikita Mounier (Apr 06 2022 at 22:33):

Hi, I'm sorry if messages in this thread are getting a bit repetitive with people getting some variation of the same error when building from source...
When I run cargo build, I get this error:

error: failed to run custom build command for `roc_builtins v0.1.0 (/Users/nikitamounier/Desktop/roc/compiler/builtins)`

Caused by:
  process didn't exit successfully: `/Users/nikitamounier/Desktop/roc/target/debug/build/roc_builtins-4cc28b6b1e39ca55/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  Compiling host ir to: /Users/nikitamounier/Desktop/roc/compiler/builtins/bitcode/builtins-host.ll

  --- stderr
  thread 'main' panicked at 'zig failed: error: unable to create compilation: FileNotFound
  ', compiler/builtins/build.rs:170:17
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

I'm running macOS Monterey on an M1 with the nix-shell. According to llvm-config --version, I'm on LLVM 12.01, and according to zig version I'm on zig 0.8.1. I'm able to run zig build run on a simple hello-world zig project.

Brendan Hansknecht (Apr 06 2022 at 22:41):

Sometimes that just flakily fails on my M1 mac and I simply have to run cargo build twice. So try running it again before anything else

Nikita Mounier (Apr 06 2022 at 22:49):

Hi! Yeah I've tried running cargo build a couple times now, quit my terminal session in between sometimes and all. No luck for me yet, still getting the same error message

Brendan Hansknecht (Apr 06 2022 at 22:59):

Just a note, one general option is just to use nix and it should auto-magically work. Otherwise, I'll try to look into this more in a bit to figure out what is going on.

Nikita Mounier (Apr 06 2022 at 23:07):

That's just the thing --- I am using nix (that's what I meant when I said I'm on an M1 with nix-shell), which makes it all the more perplexing...

Brendan Hansknecht (Apr 07 2022 at 00:32):

Sorry, I missed the nix line. Can you run with RUST_BACKTRACE=1 I want to see which specific zig command is failing

Brendan Hansknecht (Apr 07 2022 at 00:56):

Nikita Mounier (Apr 07 2022 at 01:18):

stack backtrace:
     0: rust_begin_unwind
               at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
     1: core::panicking::panic_fmt
               at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
     2: build_script_build::run_command
               at ./build.rs:170:17
     3: build_script_build::generate_bc_file
               at ./build.rs:134:5
     4: build_script_build::main
               at ./build.rs:39:5
     5: core::ops::function::FnOnce::call_once
               at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Brendan Hansknecht (Apr 07 2022 at 02:50):

So I think something is likely messed up with how we setup zig with nix. In a pure nix shell we have some interesting behaviour:

[nix-shell:~/Projects/roc]$ mkdir test

[nix-shell:~/Projects/roc]$ cd test

[nix-shell:~/Projects/roc/test]$ zig init-exe
info: Created build.zig
info: Created src/main.zig
info: Next, try `zig build --help` or `zig build run`

[nix-shell:~/Projects/roc/test]$ zig build --help
error: unable to create compilation: FileNotFound

Brendan Hansknecht (Apr 07 2022 at 02:50):

I think the files that are failing to compile are the zig build cache for the standard library or something of that nature. I think nix may be restricting file writing permissions. That is at least my first guess.

Brendan Hansknecht (Apr 07 2022 at 02:52):

Potentially a work around is just making sure that people never use pure nix shells or use tools like direnv/lorri, but I am not sure if they would still run into the issue either way.

jan kili (Apr 07 2022 at 02:57):

Brendan Hansknecht (Apr 07 2022 at 03:22):

I have been poking at this for a bit, and at least for now, I am unsure what specifically is going on. Though I did learn that gimmeMoreOfThoseSweetSweetFileDescriptors() is a function in the zig compiler.

Brendan Hansknecht (Apr 07 2022 at 03:25):

Since the compiler is about to update zig versions, this should be fixed very soon.

Brendan Hansknecht (Apr 07 2022 at 03:32):

The zig 0.9.1 branch isn't fully working, but @Nikita Mounier can you check if you can at least build the compiler on the update_zig_09 branch? (please git pull I just pushed a change to it)

Nikita Mounier (Apr 07 2022 at 11:19):

Nikita Mounier (Apr 07 2022 at 11:44):

Nikita Mounier (Apr 07 2022 at 11:45):

Folkert de Vries (Apr 07 2022 at 11:46):

macos is rather strict in going out of bounds so if you see random segfaults, that might be it

Folkert de Vries (Apr 07 2022 at 11:47):

I'll continue work on it tonight/over the weekend, so it should all be fixed soon

Nikita Mounier (Apr 07 2022 at 11:47):

I see, thanks for the info. Should be fine for now for me to hack around a little with Roc

Nikita Mounier (Apr 07 2022 at 11:47):

Nikita Mounier (Apr 07 2022 at 12:01):

Ok actually although I'm able to build the compiler, I'm not able to compile a Roc file. When doing cargo run examples/hello-world/helloWorld.roc, I get this error with this stacktrace:

🔨 Rebuilding host... Done!
thread 'main' panicked at 'Failed to execute command 'sw_vers -productVersion': Os { code: 2, kind: NotFound, message: "No such file or directory" }', compiler/build/src/link.rs:1006:10
stack backtrace:
   0: rust_begin_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
   2: core::result::unwrap_failed
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1613:5
   3: core::result::Result<T,E>::expect
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1255:23
   4: roc_build::link::get_macos_version
             at /Users/nikitamounier/Desktop/roc/compiler/build/src/link.rs:1003:22
   5: roc_build::link::link_macos
             at /Users/nikitamounier/Desktop/roc/compiler/build/src/link.rs:931:14
   6: roc_build::link::link
             at /Users/nikitamounier/Desktop/roc/compiler/build/src/link.rs:48:14
   7: roc_cli::build::build_file
             at /Users/nikitamounier/Desktop/roc/cli/src/build.rs:259:13
   8: roc_cli::build
             at /Users/nikitamounier/Desktop/roc/cli/src/lib.rs:332:27
   9: roc::main
             at /Users/nikitamounier/Desktop/roc/cli/src/main.rs:30:21
  10: core::ops::function::FnOnce::call_once
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/ops/function.rs:227:5

Same thing happens with cargo run --release.
I did a quick search on the Zulip chat to see if this error has already popped up for someone, but it seems like it hasn't. What do you think?

Folkert de Vries (Apr 07 2022 at 12:08):

Nikita Mounier (Apr 07 2022 at 12:47):

I'm not sure whether this is helpful or not, but I get a different (probably related) error when running cargo run examples/algorithms/fibonacci.roc:

thread '<unnamed>' panicked at 'TODO gracefully handle unsupported target: Triple { architecture: Aarch64(Aarch64), vendor: Apple, operating_system: Darwin, environment: Unknown, binary_format: Macho }', compiler/build/src/target.rs:75:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
   2: roc_build::target::target_zig_str
             at ./compiler/build/src/target.rs:75:14
   3: roc_build::link::rebuild_host
             at ./compiler/build/src/link.rs:460:21
   4: roc_cli::build::spawn_rebuild_thread::{{closure}}
             at ./cli/src/build.rs:326:17
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', cli/src/build.rs:233:50
stack backtrace:
   0: rust_begin_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
   2: core::result::unwrap_failed
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1613:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1295:23
   4: roc_cli::build::build_file
             at ./cli/src/build.rs:233:28
   5: roc_cli::build
             at ./cli/src/lib.rs:332:27
   6: roc::main
             at ./cli/src/main.rs:30:21
   7: core::ops::function::FnOnce::call_once

Folkert de Vries (Apr 07 2022 at 12:50):

huh, that unsupported target is weird. @Brendan Hansknecht how could that happen? you run roc on your M1 right?

Ayaz Hafiz (Apr 07 2022 at 12:58):

Nikita Mounier (Apr 07 2022 at 13:00):

I've been running most of the example files to see the different kind of errors I get, it seems like I only get the unsupported target error with algorithms/quicksort.roc, algorithms/fibonacci.roc, and effects/Effect.roc
For the other files it's just the memory-related one

Ayaz Hafiz (Apr 07 2022 at 13:03):

Nikita Mounier (Apr 07 2022 at 13:05):

Darwin Nikitas-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:36:53 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T8101 arm64 arm64 MacBookPro17,1 Darwin
bash: arch: command not found

Ayaz Hafiz (Apr 07 2022 at 13:10):

Nikita Mounier (Apr 07 2022 at 13:12):

Ok, I think I've confirmed that the unsupported-platform error only shows up when using a zig platform in the Roc file. For instance in examples/hello-world/helloWorld.roc, I get the usual memory-related error for c and rust, but only get the unsupported platform one when using zig. The two algorithm files and the Effects.roc file also use zig as the platform.

Nikita Mounier (Apr 07 2022 at 13:14):

I'm on the update_zig_09 branch using the latest commit dcc876d03aa5df139a6f5402c9d348f5e1be184b

Ayaz Hafiz (Apr 07 2022 at 13:17):

Yeah that makes sense, you're hitting a panic in the function that gets the target for building zig code. Looks like that commit is missing the branch for Darwin on Mac. I just pushed 29739876876335b5ab4ca79b04290c58bb7749ed to that branch that should fix it; can you try?

Nikita Mounier (Apr 07 2022 at 13:17):

I'm actually also getting the same unsupported-platform error when using web-platform in the helloWorld.roc. Not sure if that's related though

Nikita Mounier (Apr 07 2022 at 13:18):

Nikita Mounier (Apr 07 2022 at 13:24):

Ok, so I tried compiling algorithms/fibonacci.roc and hello-world/helloWorld.roc using zig-platform, and I'm not getting the unsupported-platform error anymore, but I am getting a new kind of error:

thread '<unnamed>' panicked at 'Failed to rebuild host.zig - stderr of the `zig` command was:
/Users/nikitamounier/Desktop/roc/examples/algorithms/fibonacci-platform/host.zig:28:69: error: use of undeclared identifier 'c_void'
/Users/nikitamounier/Desktop/roc/examples/algorithms/fibonacci-platform/host.zig:29:84: error: use of undeclared identifier 'c_void'
/Users/nikitamounier/Desktop/roc/examples/algorithms/fibonacci-platform/host.zig:34:65: error: use of undeclared identifier 'c_void'
/Users/nikitamounier/Desktop/roc/examples/algorithms/fibonacci-platform/host.zig:45:31: error: use of undeclared identifier 'c_void'
/Users/nikitamounier/Desktop/roc/examples/algorithms/fibonacci-platform/host.zig:54:31: error: use of undeclared identifier 'c_void'
/Users/nikitamounier/Desktop/roc/examples/algorithms/fibonacci-platform/host.zig:63:29: error: use of undeclared identifier 'c_void'
', compiler/build/src/link.rs:1111:27
stack backtrace:
   0: rust_begin_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
   2: roc_build::link::validate_output
             at ./compiler/build/src/link.rs:1111:27
   3: roc_build::link::rebuild_host
             at ./compiler/build/src/link.rs:469:9
   4: roc_cli::build::spawn_rebuild_thread::{{closure}}
             at ./cli/src/build.rs:326:17
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', cli/src/build.rs:233:50
stack backtrace:
   0: rust_begin_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
   2: core::result::unwrap_failed
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1613:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1295:23
   4: roc_cli::build::build_file
             at ./cli/src/build.rs:233:28
   5: roc_cli::build
             at ./cli/src/lib.rs:332:27
   6: roc::main
             at ./cli/src/main.rs:30:21
   7: core::ops::function::FnOnce::call_once
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/ops/function.rs:227:5

Ayaz Hafiz (Apr 07 2022 at 13:33):

Okay I fixed the zig errors and I think it should actually work now. Can you pull and try?

Nikita Mounier (Apr 07 2022 at 13:38):

Yep, I'm not getting the zig-specific errors anymore (except in interactive/effects.roc which I forgot to mention up above) – I'm only getting the memory-related errors now from before

Ayaz Hafiz (Apr 07 2022 at 13:39):

Pushed compile error fixes for effects.roc now too, but there are segfaults there when you actually run it :)

Ayaz Hafiz (Apr 07 2022 at 13:41):

Nikita Mounier (Apr 07 2022 at 14:08):

Nikita Mounier (Apr 07 2022 at 14:09):

Ayaz Hafiz (Apr 07 2022 at 14:11):

Is /usr/bin in your path? Your error with cargo run examples/hello-world/helloWorld.roc is presumably because sw_vers couldn't be run

Nikita Mounier (Apr 07 2022 at 15:02):

You're right that's my mistake --- my default shell is fish, but I forgot that nix uses bash, so had to update my .bashrc path.

Nikita Mounier (Apr 07 2022 at 15:08):

So I'm back to getting the same zig error as before (the c_void) one from up above, with the same stacktrace, in interactive/tui.roc and hello-world/helloWorld.roc (on zig-platform). Otherwise, everything else compiles very nicely! Just whenever I do some Stdin input (like on interactive/echo.roc), I get back a seg fault 11.

Brendan Hansknecht (Apr 07 2022 at 15:13):

I think c_void was just a change between zig 0.8.1 an 0.9.1. So the example probably hasn't been updated yet

Brendan Hansknecht (Apr 07 2022 at 15:13):

Nikita Mounier (Apr 07 2022 at 19:31):

It's been working like a charm, until just recently where whenever I try to do a cargo build or cargo run, it's unable to compile the roc_cli with:

error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-arch" "arm64" ......
  = note: ld: library not found for -ltinfo
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

I'm not sure why this error is popping up now, I don't think I changed anything or inadvertently removed a file. I downloaded a clean build of the repo and all, but to no avail --- same error.

Nikita Mounier (Apr 08 2022 at 18:43):

I've been looking around online to see how to fix the issue – I found this potential solution:

cd /usr/lib
ln -s libncurses.so.5 libtinfo.so.5
ln -s libtinfo.so.5 libtinfo.so

Ayaz Hafiz (Apr 08 2022 at 18:44):

Nikita Mounier (Apr 08 2022 at 18:55):

Nikita Mounier (Apr 08 2022 at 18:56):

Ayaz Hafiz (Apr 08 2022 at 18:58):

I think you want the cc from nix. If you updated your bashrc, maybe you want to add /usr/bin to the back of the path rather than the front?

Folkert de Vries (Apr 08 2022 at 19:00):

btw that branch should be a lot more usable now, basically everything besides the wasm backend seems to at least work

Folkert de Vries (Apr 08 2022 at 19:00):

there are some tricky memory-related issues still, but those won't come up often if you're just playing around

Nikita Mounier (Apr 08 2022 at 19:18):

I actually ended up downloading a plugin that lets me use fish with nix. Weird thing is, all of the nix-related things like /Users/nikitamounier/.nix-profile/bin are already at the front path.
Here's my PATH for reference:

/nix/var/nix/profiles/default/bin /Users/nikitamounier/.nix-profile/bin /usr/bin /opt/homebrew/opt/libpq/bin /opt/homebrew/opt/llvm@12/bin /usr/local/bin /Users/nikitamounier/.cargo/bin /opt/homebrew/bin //opt/homebrew/bin /Users/nikitamounier/.fig/bin /Users/nikitamounier/.fzf/bin /bin /usr/sbin /sbin /opt/X11/bin /Library/Apple/usr/bin /Library/TeX/texbin /Applications/kitty.app/Contents/MacOS

Ayaz Hafiz (Apr 08 2022 at 19:25):

In my nix shell I see a bunch of opaque paths to stuff in nix/store at the front of my path

Nikita Mounier (Apr 08 2022 at 19:58):

:face_palm: Forgot that nix-shell has a different PATH. Attempting to move usr/bin to the end of the path, but fish is giving me a weirdly difficult time...

Nikita Mounier (Apr 08 2022 at 20:12):

You were right! I was able to finally get the usr/bin to move at the end of PATH, and now it all works. Maybe someone could add to BUILDING_FROM_SOURCE.md that people using nix-shell should do this? I'll be happy to open a PR

Ayaz Hafiz (Apr 08 2022 at 20:18):

Nikita Mounier (Apr 08 2022 at 21:22):

Sounds good! Yeah, looks like Stdin still doesn't work for me (getting a SIGSEGV), I guess I'll try to avoid that for now. Everything else works like a charm though!

Nikita Mounier (Apr 08 2022 at 23:49):

Actually, it's only the effects-platform and the cli-platform (from examples/interactive) that segfault on user input, the rest work great!

Nikita Mounier (Apr 14 2022 at 13:13):

I see the Update to Zig 0.9 PR doesn't say WIP anymore – so this will merge with trunk/upstream soon?

Folkert de Vries (Apr 14 2022 at 13:15):

Folkert de Vries (Apr 14 2022 at 13:16):

so we don't want to do that before Richard records his demo, but soon after probably

Nikita Mounier (Apr 14 2022 at 13:16):

Nikita Mounier (Apr 14 2022 at 13:17):

Yeah I guess it'll be a smoother experience for those of us who are on nix-shell

Folkert de Vries (Apr 14 2022 at 13:20):

yeah and in general the upgrade process is a lot smoother now than it was in the past. We know (kinda) what we're doing now

Folkert de Vries (Apr 14 2022 at 13:20):

Viktor Ferenczi (Apr 15 2022 at 00:42):

Trying to build Roc from GitHub repo sources on Ubuntu 20.04 running inside WSL (not WSL2).

Build with /nix/store/m0xw42nwrlfznfasiqfzwdavi4421x32-ghc-8.10.7.
ghc-pkg: Couldn't open database /tmp/nix-build-niv-0.2.19.drv-0/setup-package.conf.d for modification: {handle: /tmp/nix-build-niv-0.2.19.drv-0/setup-package.conf.d/package.cache.lock}: hLock: invalid argument (Invalid argument)
error: builder for '/nix/store/k5cy1lsddvq61hni78jdfyls8rf2ybsk-niv-0.2.19.drv' failed with exit code 1
error: build of '/nix/store/10p69ddbzjzbln6zhpkxlgywlqm6ax3w-zig-0.8.1.drv', '/nix/store/ac6vy5ly0is5xr7jnhabr2kd975gvi6p-debugir.drv', '/nix/store/k5cy1lsddvq61hni78jdfyls8rf2ybsk-niv-0.2.19.drv' failed

Brendan Hansknecht (Apr 15 2022 at 00:52):

Viktor Ferenczi (Apr 15 2022 at 12:02):

Anton (Apr 15 2022 at 12:13):

Brian Carroll (Apr 21 2022 at 21:07):

I'm installing Roc on a new installation of Ubuntu 20.04. Installed nix and all the packages. But now I keep getting this error. Any ideas how to fix it?

[nix-shell:~/code/roc]$ nix rebuild
nix: /nix/store/nprym6lf8lzhp1irb42lb4vp8069l5rj-glibc-2.32-54/lib/libc.so.6: version `GLIBC_2.33' not found (required by /nix/store/dd8swlwhpdhn6bv219562vyxhi8278hs-gcc-10.3.0-lib/lib/libstdc++.so.6)

Brian Carroll (Apr 21 2022 at 21:17):

Actually I still seem to be able to run cargo and things, so it doesn't seem to be really blocking me

Brian Carroll (Apr 22 2022 at 06:16):

[nix-shell:~/code/roc]$ perf record target/debug/roc build examples/false-interpreter/False.roc
/bin/bash: /nix/store/wgp4l0jl7hm510x5615qsv4xikybzqb3-ncurses-6.2/lib/libtinfo.so.6: no version information available (required by /bin/bash)
/bin/bash: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /nix/store/wgp4l0jl7hm510x5615qsv4xikybzqb3-ncurses-6.2/lib/libtinfo.so.6)

Brian Carroll (Apr 22 2022 at 06:21):

Anyone else using Ubuntu 20.04 with nix? Have you seen anything like this? Did you solve it?

Anton (Apr 22 2022 at 07:09):

building will spam a different ncurses message but as far as I could tell that one does not affect anything.

Eric Guedes Pinto (Aug 12 2022 at 19:17):

Hi! I am having trouble compiling from source in an ubuntu VM running on an M1 mac.

       Did you mean devShell?

I solved this by adding "aarch64-linux" to the supportedSystems in the flake.nix file.

   --> crates/linker/src/lib.rs:505:65
    |
505 | ...                   let c_str = unsafe { CStr::from_ptr(str_bytes.as_ptr() as *const i8) };
    |                                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
    |
    = note: expected raw pointer `*const u8`
               found raw pointer `*const i8`

error[E0308]: mismatched types
    --> crates/linker/src/lib.rs:1811:40
     |
1811 |             let c_buf: *const c_char = dynstr_data[dynstr_off..].as_ptr() as *const i8;
     |                        -------------   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
     |                        |
     |                        expected due to this
     |
     = note: expected raw pointer `*const u8`
                found raw pointer `*const i8`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `roc_linker` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

Has anyone seen this before? it is a type mismatch from the linker, so this should have come up before right?
I installed everything from scratch following the build from source file.
My system is updated.
Could it be related to the issues with the silicon-Mac platform? Or versioning of some of the required libraries?

Notification Bot (Aug 12 2022 at 19:18):

Notification Bot (Aug 12 2022 at 19:20):

Anton (Aug 12 2022 at 19:20):

Hi eric, we do not (yet?) support the aarch64-linux platform. You should be able to run on macos aarch64 though.

Eric Guedes Pinto (Aug 12 2022 at 19:21):

Anton (Aug 12 2022 at 19:37):

Brendan Hansknecht (Aug 12 2022 at 20:57):

Oh, the second issue is a bug I have run into before and keep forgetting to fix. We just need to update some types as the error says.

Brendan Hansknecht (Aug 12 2022 at 20:58):

I developed that on x86, but didn't think about generic types because char is unsigned on some platforms and signed on others.

Brendan Hansknecht (Aug 12 2022 at 20:58):

Ross Smyth (Aug 14 2022 at 02:11):

note: lld: error: undefined symbol: roc_alloc
          >>> referenced by C:\Users\RossSmyth\Documents\roc\crates\roc_std\src\lib.rs:51
          >>>               libroc_std-c05e5e25b8ffcb50.rlib(roc_std-c05e5e25b8ffcb50.46ifwog7cqzs4dpa.rcgu.o):(roc_std::roc_alloc_refcounted_help::h08260161a777fba6)

error: could not compile `roc_load` due to previous error

Richard Feldman (Aug 14 2022 at 02:46):

Folkert de Vries (Aug 14 2022 at 12:56):

I'll need some more info here. What are you trying to build (what is the command) and where exactly does it fail?

Folkert de Vries (Aug 14 2022 at 12:57):

and yeah the status of windows is: I got it to work once on one machine a little while ago

Ross Smyth (Aug 14 2022 at 18:07):

Folkert de Vries (Aug 14 2022 at 18:08):

Ross Smyth (Aug 14 2022 at 18:09):

Folkert de Vries (Aug 14 2022 at 18:09):

we recently added a flag ROC_SKIP_SUBS_CACHE=1 cargo run that should at least make that part work

Ross Smyth (Aug 14 2022 at 18:09):

Ross Smyth (Aug 14 2022 at 18:10):

Ross Smyth (Aug 14 2022 at 18:17):

Still fails, same location and error. Watching it closely as it is building it seems to fail specifically in the roc_load build.rs. I did do cargo +1.61.0-msvc cleanto be safe as well.

Folkert de Vries (Aug 14 2022 at 18:23):

Folkert de Vries (Aug 14 2022 at 18:24):

Folkert de Vries (Aug 14 2022 at 18:25):

the thing is, msvc on windows does not seem to do dead code elimination, so those function, that are not used, still need to be there on windows for some reason

Folkert de Vries (Aug 14 2022 at 18:25):

it is weird that lld also needs them to be there. But maybe this is really a windows-specific thing

Folkert de Vries (Aug 14 2022 at 18:30):

Folkert de Vries (Aug 14 2022 at 18:31):

Ross Smyth (Aug 14 2022 at 19:48):

I nuked my repo and recloned it just to be extra safe, checked out that branch, and same error. It is ignoring them because I get the "unused..." warnings, for example "warning: constant is never used: SKIP_SUBS_CACHE"

I then tried to build it in release (cargo +1.61.0 build --release) since LTO is on in release mode. There are spurious other linker failures in Zig in release before the failure above. Seems to do with file locking? But on a "good " run it still hit the failure above.

My next train of thought was maybe some weird parallel compilation race condition was messing things up, so I attempted to build with cargo +1.61.0-msvc build -j 0. Same failure.

Folkert de Vries (Aug 14 2022 at 20:04):

ok well you should now be able to just comment pretty much all of that build.rs away

Folkert de Vries (Aug 14 2022 at 20:04):

and yes on windows for now at least you'll get a bunch of unused warnings in many places.

Ross Smyth (Aug 14 2022 at 20:10):

I just deleted the build file and roc_load finally built! But now the same error some from both roc_cli and roc_docs_cli :sad:

Richard Feldman (Aug 14 2022 at 20:30):

if anyone is interested in picking it up, we'd be happy to help you get started on it!

Folkert de Vries (Aug 14 2022 at 20:59):

Ross Smyth (Aug 14 2022 at 22:07):

That "worked" with some further modification. I'll write up something in an issue.

Ross Smyth (Aug 14 2022 at 23:11):

Thomas Dwyer (Aug 15 2022 at 00:10):

I don't have much experience in git PRs nor much with Rust, but this seems very approachable. Where could I get started on it? (i also need to get my nix environment set up for the latest version of the compiler, but that's a different issue)

Ayaz Hafiz (Aug 15 2022 at 00:37):

Thomas Dwyer (Aug 15 2022 at 01:48):

Building everything works currently, but i run those tests after building the cli and i get a complaint about not finding GLIBC_2.34 for wasm3-sys. Checking the chat history here and on the issues page says using flakes solves this, but i am using flakes. My system libc version is 2.33 but in the nix develop environment it is 2.34. Any ideas? (This should be moved to #beginners > building from source )

Notification Bot (Aug 15 2022 at 02:07):

Anton (Aug 15 2022 at 09:29):

Hi @Thomas Dwyer, I'll try to look at your issue today. Can you tell me the exact sequence of commands you ran?

Thomas Dwyer (Aug 15 2022 at 09:32):

well i entered the nix shell with nix develop, built the roc cli using cargo build -p roc_cli, then simply ran cargo test repl_test (cargo test has the same issue). i get the following error:
image.png

Anton (Aug 15 2022 at 09:38):

Anton (Aug 15 2022 at 10:10):

I failed to reproduce this on NixOS, can you tell me what operating system you are on @Thomas Dwyer?

Thomas Dwyer (Aug 15 2022 at 16:07):

@Anton I am running WSL2 under my windows 10 pc. This is a single user nix installation.

Anton (Aug 15 2022 at 16:30):

Anton (Aug 21 2022 at 06:44):

@Thomas Dwyer can you try nix develop followed by cargo clean and cargo build? Doing that fixed it for someone else with a very similar error.

Thomas Dwyer (Aug 21 2022 at 17:49):

@Anton Thank you, that works! really strange! Perhaps there should be a troubleshooting section in the installation file for cases like this. Nix is a strange beast for many people (including me), so we should aim to make its use as simple as possible. I really do wonder why nix was doing this, but I'm not too bothered now that it's solved.

Brendan Hansknecht (Aug 21 2022 at 17:54):

Generally that happens when you build outside of nix and that pulls in the system Glibc then nix breaks due to linking to object files with the wrong glibc.

Anton (Aug 22 2022 at 06:57):

Yes indeed, simply put it's because you probably did cargo build without doing nix develop first. I will mention this in BUILDING_FROM_SOURCE and create an issue for it so people can also find it that way.

Bryce Miller (Aug 29 2022 at 11:49):

When running nix develop, I get an error linking debugir. Does this sound like an issue with my Nix setup or somerhing else? (WSL2, Ubuntu 22.04). Happy to share logs if that would be helpful.

Anton (Aug 29 2022 at 16:05):

Hi @Bryce Miller, that is unexpected. A detailed error message and logs would indeed be very helpful.

Anton (Aug 29 2022 at 16:08):

I'm also setting up a 22.04 virtual machine, the error did not reproduce on 20.04.

Bryce Miller (Aug 29 2022 at 16:11):

Bryce Miller (Aug 29 2022 at 16:12):

I believe it was working when I had 20.04 under WSL2 on my win10 box. Can't quite remember though.

Bryce Miller (Aug 29 2022 at 16:14):

Curious to find out whether you get the same error on your VM. If not, maybe something peculiar about WSL?

Bryce Miller (Aug 29 2022 at 16:18):

error: builder for '/nix/store/8c55wxck5wxir0gsycdwxcdsa62ng41l-debugir.drv' failed with exit code 2;
       last 10 log lines:
       > /nix/store/vhf2cr6immz4qdxd83y025fnxim8mmfg-binutils-2.38/bin/ld: Main.cpp:(.text.startup+0xaf9): undefined reference to `llvm::raw_string_ostream::~raw_string_ostream()'
       > /nix/store/vhf2cr6immz4qdxd83y025fnxim8mmfg-binutils-2.38/bin/ld: CMakeFiles/debugir.dir/Main.cpp.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE[_ZTIN4llvm2cl15OptionValueCopyINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
       > /nix/store/vhf2cr6immz4qdxd83y025fnxim8mmfg-binutils-2.38/bin/ld: CMakeFiles/debugir.dir/Main.cpp.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyIbEE[_ZTIN4llvm2cl15OptionValueCopyIbEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
       > /nix/store/vhf2cr6immz4qdxd83y025fnxim8mmfg-binutils-2.38/bin/ld: CMakeFiles/debugir.dir/Main.cpp.o:(.data.rel.ro._ZTVN4llvm2cl15OptionValueCopyINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE[_ZTVN4llvm2cl15OptionValueCopyINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE]+0x18): undefined reference to `llvm::cl::GenericOptionValue::anchor()'
       > /nix/store/vhf2cr6immz4qdxd83y025fnxim8mmfg-binutils-2.38/bin/ld: CMakeFiles/debugir.dir/Main.cpp.o:(.data.rel.ro._ZTVN4llvm2cl11OptionValueIbEE[_ZTVN4llvm2cl11OptionValueIbEE]+0x18): undefined reference to `llvm::cl::GenericOptionValue::anchor()'
       > /nix/store/vhf2cr6immz4qdxd83y025fnxim8mmfg-binutils-2.38/bin/ld: CMakeFiles/debugir.dir/Main.cpp.o:(.data.rel+0x0): undefined reference to `llvm::DisableABIBreakingChecks'
       > collect2: error: ld returned 1 exit status
       > make[2]: *** [CMakeFiles/debugir.dir/build.make:134: debugir] Error 1
       > make[1]: *** [CMakeFiles/Makefile2:164: CMakeFiles/debugir.dir/all] Error 2
       > make: *** [Makefile:91: all] Error 2
       For full logs, run 'nix log /nix/store/8c55wxck5wxir0gsycdwxcdsa62ng41l-debugir.drv'.
error: 1 dependencies of derivation '/nix/store/6c85ff13cb9xdv6x6hmq3axrdkjj7gwc-nix-shell-env.drv' failed to build

Anton (Aug 29 2022 at 16:20):

We've had a similar issue before that I never really figured out but it disappeared with different versions of nixpkgs. Can you check with git status if the flake.lock file changed?

Bryce Miller (Aug 29 2022 at 16:23):

Bryce Miller (Aug 29 2022 at 16:32):

I was going to test on my M1 Mac last night but I managed to screw up my Nix installation lol. Last I checked it worked there.

Anton (Aug 29 2022 at 17:19):

Anton (Aug 29 2022 at 17:41):

I failed to reproduce this in the VM on Ubuntu 22.04. I'll continue to investigate but if you want to unblock yourself you can just remove the debugir line from inside sharedInputs = (with pkgs; [ in flake.nix. debugir is only used to debug a specific part of the compiler when needed, the build and tests can all pass without debugir. A similar error as you're having now can occur for another nix dependency though.

Bryce Miller (Aug 29 2022 at 17:51):

Commented out that line and it worked! Some stuff isn't building now but I'm able to get into the shell at least. It also works without issue on my mac, so I can always use that. Definitely let me know if there is anything else I can do to help troubleshoot this, and I'll let you know if I find out anything new.

Anton (Aug 29 2022 at 17:59):

I'll let you now :) I'll try it out in WSL2 tomorrow.
Can you also share the errors for "Some stuff isn't building now"? Do those errors occur when doing cargo build or is this still with nix develop?

Bryce Miller (Aug 29 2022 at 18:02):

Doing nix develop successfully puts me into the shell. cargo clean && cargo build results in the following:

...
   Compiling x11-dl v2.19.1
   Compiling wgpu-core v0.12.2
error: failed to run custom build command for `wasi_libc_sys v0.0.1 (/home/bdm/src/contrib/roc/crates/wasi-libc-sys)`

Caused by:
  process didn't exit successfully: `/home/bdm/src/contrib/roc/target/debug/build/wasi_libc_sys-ea0d16e6299e57fc/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=src/dummy.c

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', crates/wasi-libc-sys/build.rs:33:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Bryce Miller (Aug 29 2022 at 18:08):

Here's a similar error I got on my mac when I tried tocargo build before running cargo clean.

error: failed to run custom build command for `roc_repl_wasm v0.0.1 (/Users/bryce/src/roc/crates/repl_wasm)`

Caused by:
  process didn't exit successfully: `/Users/bryce/src/roc/target/debug/build/roc_repl_wasm-447f50ffdcb4a716/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=src/repl_platform.c

  --- stderr
  thread 'main' panicked at 'Output {
      status: ExitStatus(
          unix_wait_status(
              256,
          ),
      ),
      stdout: "",
      stderr: "wasm-ld: error: cannot open /Users/bryce/code/roc/target/debug/build/wasi_libc_sys-b55c70ecf1892372/out/zig-cache/o/1bb0d1cbfb762560ef47ddccdb2efdcf/compiler_rt.o: No such file or directory\nwasm-ld: error: cannot open /Users/bryce/code/roc/target/debug/build/wasi_libc_sys-b55c70ecf1892372/out/wasi-libc.a: No such file or directory\n",
  }', crates/repl_wasm/build.rs:42:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Oddly, after I got this error, cargo run repl worked without running cargo clean first. cargo clean && cargo build fixed the build issue.

So to be clear, no problems on my Mac, but this is an issue that popped up and was easily fixable with cargo clean.

Anton (Aug 30 2022 at 08:53):

You may have run cargo build once without doing nix develop first. Later trying to use nix with pre-built artifacts made without nix is known to lead to all kinds of problems. We mention this in BUILDING_FROM_SOURCE but I will improve the wording. To prevent this: tools like direnv or lorri can automatically put you in a nix shell whenever you cd into the directory, I also like using starship which clearly shows if you are in a nix shell or not.

Anton (Aug 30 2022 at 15:11):

@Bryce Miller I failed to reproduce the debugir error with Ubuntu 22.04 on WSL. Because we are working on native windows support I'd like to end the investigation here.

Bryce Miller (Aug 30 2022 at 15:26):

Thanks for the tips! I believe I did run cargo build once before remembering to drop into the Nix shell. I just didn’t know how to clean up the mess beyond trying cargo clean.

Fair enough, you have higher priority things to work on! If I do manage to figure out a fix, should I share it here?

Bryce Miller (Aug 30 2022 at 15:26):

Bryce Miller (Aug 31 2022 at 16:10):

Update: I tried using the "Ubuntu 22.04.1" package from the Microsoft Store instead of the "Ubuntu" package. Nix shell and build worked flawlessly. Either I messed something up in the other environment, or there is some subtle difference in the way they are set up by default. Hope this helps for anyone else using WSL2.

Hashi364 (Sep 08 2022 at 22:24):

nix develop
cargo install

error: found a virtual manifest at `/path/to/roc/Cargo.toml` instead of a package manifest

Folkert de Vries (Sep 08 2022 at 22:24):

Hashi364 (Sep 08 2022 at 22:29):

Where is the binary?
Sorry, I forgot to say that I want a binary and not to run cargo run -- foo every time

Folkert de Vries (Sep 08 2022 at 22:29):

/target/debug/roc probably, or /target/release/roc is you built with --release

Folkert de Vries (Sep 08 2022 at 22:30):

you should symlink that though, and not move the binary; it uses some files with a relative path

Hashi364 (Sep 08 2022 at 22:31):

Arbil (Oct 16 2022 at 05:54):

Brendan Hansknecht (Oct 16 2022 at 05:58):

That should work if you have nix setup correctly and direnv installed through nix

Brendan Hansknecht (Oct 16 2022 at 05:59):

It basically rebuilds the nix environment behind the scenes and caches the nix environment better. So you can just use things without waiting on updates.

Chad Stearns (Oct 17 2022 at 00:14):

Hello! I am coming back to Roc since last working on it around February. Trying to build from source now, I am hitting this exact error Bryce reported. For me, cargo clean is not resolving. Has anyone else run into it?

Chad Stearns (Oct 17 2022 at 00:16):

Brian Carroll (Oct 17 2022 at 07:19):

Hi Chad, that error suggests that a previous Zig command failed. Maybe check what zig version says? We require Zig 0.9.1. We first check to see if the environment variable ROC_ZIG contains a path, and if not, we default to zig.

Anton (Oct 17 2022 at 10:00):

Welcome back @Chad Stearns :)
Like Bryce, did you also do nix develop first? Zig should definitely be the right version when using nix develop.

Arbil (Oct 17 2022 at 14:06):

Thanks, it's working. However, every call of nix develop, or entry through direnv, takes away about 10GB of disk space which quickly kills this resource constrained box. Part of that seems copying of roc-main directory with all the compilation artifacts. nix-collect-garbage on the other hand forces download & install of all dependencies again (and doesn't seem to free all the disk space anyway)

Arbil (Oct 17 2022 at 14:06):

Brendan Hansknecht (Oct 17 2022 at 15:46):

Yeah....nix can be annoying with storage space. I have never run out of space on my machine, so I can't imagine the 10 GB being consistently added without some other form of issue (though even a few times could be problematic). @Anton any ideas? Can we get nix to ignore the files? Especially the target folder? Theoretically, nix should be able to just change paths and not move any data, right?

Brian Hicks (Oct 17 2022 at 15:49):

I like using https://github.com/hercules-ci/gitignore.nix for this but it only makes sense for the shell.nix/default.nix combo. If you have a version of Nix that can use flakes, I'd recommend using use flake in your .envrc instead, as it'll ignore gitignored files automatically.

Brian Hicks (Oct 17 2022 at 15:49):

(although I think nix develop uses flakes already so I am not sure what could be happening there.)

Brendan Hansknecht (Oct 17 2022 at 15:50):

Brendan Hansknecht (Oct 17 2022 at 15:57):

Also, didn't realize direnv can support flakes directly now. Might switch to that until lorri updates.

Brian Hicks (Oct 17 2022 at 16:00):

I switched away from Lorri a long time ago, FWIW. The only thing I miss is building in the background. I've got a direnv snippet loaded with home-manager that caches shells so that shell startup is negligible with just use nix or use flake without having to run a daemon.

Brian Hicks (Oct 17 2022 at 16:00):

Brendan Hansknecht (Oct 17 2022 at 16:07):

Anton (Oct 17 2022 at 17:31):

I don't think compilation artifacts are copied, but once you run cargo build after nix develop they will appear in the nix/store/hash-source folder.

Anton (Oct 17 2022 at 17:54):

@Arbil I would check your target folder to make sure that you don't have both release and debug folders. Your IDE may also generate compiler artifacts. I would delete the debug folder and test building with cargo build --release -p name_of_crate_you_changed and testing with cargo test --release -p name_of_crate_you_changed to save storage space. I will send you a flake.nix tomorrow that does not contain the editor's dependencies, that should also save some space.

Arbil (Oct 18 2022 at 04:57):

Thank you. I've done a quick reformat of this box and it seems more managable this time. BTW, I'm using the vscode flake and 'arrow up' doesn't work in inbuilt terminal for 'previous command', is that normal?

Brendan Hansknecht (Oct 18 2022 at 04:59):

Anton (Oct 18 2022 at 06:09):

Yeah it's not just the different histories, I also have this. I tried digging into it but came up empty, so I use the terminal in which I entered nix develop.

Brendan Hansknecht (Oct 18 2022 at 06:11):

Anton (Oct 18 2022 at 06:15):

Arbil (Oct 18 2022 at 08:47):

Anton (Oct 18 2022 at 10:18):

{
  description = "Roc flake";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";

    # rust from nixpkgs has some libc problems, this is patched in the rust-overlay
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    # to easily make configs for multiple architectures
    flake-utils.url = "github:numtide/flake-utils";
    # to be able to use vulkan system libs for editor graphics
    nixgl = {
      url = "github:guibou/nixGL";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = { self, nixpkgs, rust-overlay, flake-utils, nixgl }:
    let supportedSystems = [ "x86_64-linux" "x86_64-darwin" "aarch64-darwin" ];
    in flake-utils.lib.eachSystem supportedSystems (system:
      let
        overlays = [ (import rust-overlay) ]
          ++ (if system == "x86_64-linux" then [ nixgl.overlay ] else [ ]);
        pkgs = import nixpkgs { inherit system overlays; };
        llvmPkgs = pkgs.llvmPackages_13;

        # get current working directory
        cwd = builtins.toString ./.;
        rust =
          pkgs.rust-bin.fromRustupToolchainFile "${cwd}/rust-toolchain.toml";

        linuxInputs = with pkgs;
          lib.optionals stdenv.isLinux [
            valgrind # used in cli tests, see cli/tests/cli_run.rs
            #vulkan-headers
            #vulkan-loader
            #vulkan-tools
            #vulkan-validation-layers
            #xorg.libX11
            #xorg.libXcursor
            #xorg.libXrandr
            #xorg.libXi
            xorg.libxcb
            #alsa-lib
          ];

        darwinInputs = with pkgs;
          lib.optionals stdenv.isDarwin
          (with pkgs.darwin.apple_sdk.frameworks; [
            AppKit
            CoreFoundation
            CoreServices
            CoreVideo
            Foundation
            Metal
            Security
          ]);

        # For debugging LLVM IR
        #debugir = pkgs.stdenv.mkDerivation {
        #  name = "debugir";
        #  src = pkgs.fetchFromGitHub {
        #    owner = "vaivaswatha";
        #    repo = "debugir";
        #    rev = "b981e0b74872d9896ba447dd6391dfeb63332b80";
        #    sha256 = "Gzey0SF0NZkpiObk5e29nbc41dn4Olv1dx+6YixaZH0=";
        #  };
        #  buildInputs = with pkgs; [ cmake libxml2 llvmPackages_13.llvm.dev ];
        #  buildPhase = ''
        #    mkdir build
        #    cd build
        #    cmake -DLLVM_DIR=${pkgs.llvmPackages_13.llvm.dev} -DCMAKE_BUILD_TYPE=Release ../
        #    cmake --build ../
        #    cp ../debugir .
        #  '';
        #  installPhase = ''
        #    mkdir -p $out/bin
        #    cp debugir $out/bin
        #  '';
        #};

        sharedInputs = (with pkgs; [
          # build libraries
          cmake
          git
          python3
          llvmPkgs.llvm.dev
          llvmPkgs.clang
          libxkbcommon
          pkg-config
          zig # roc builtins are implemented in zig, see compiler/builtins/bitcode/

          # lib deps
          libffi
          libxml2
          ncurses
          zlib
          libiconv

          # faster builds - see https://github.com/roc-lang/roc/blob/main/BUILDING_FROM_SOURCE.md#use-lld-for-the-linker
          llvmPkgs.lld
          #debugir
          rust
          rust-bindgen
        ]);
      in {

        devShell = pkgs.mkShell {
          buildInputs = sharedInputs ++ darwinInputs ++ linuxInputs
            ++ (if system == "x86_64-linux" then
              [ pkgs.nixgl.nixVulkanIntel ]
            else
              [ ]);

          LLVM_SYS_130_PREFIX = "${llvmPkgs.llvm.dev}";
          # nix does not store libs in /usr/lib or /lib
          NIX_GLIBC_PATH =
            if pkgs.stdenv.isLinux then "${pkgs.glibc.out}/lib" else "";
          LD_LIBRARY_PATH = with pkgs;
            lib.makeLibraryPath
            ([ pkg-config stdenv.cc.cc.lib libffi ncurses zlib ]
              ++ linuxInputs);
          NIXPKGS_ALLOW_UNFREE =
            1; # to run the editor with NVIDIA's closed source drivers
        };

        formatter = pkgs.nixpkgs-fmt;

        # You can build this package (the roc CLI) with the `nix build` command.
        packages.default = import ./. { inherit pkgs; };
      });
}

Arbil (Oct 18 2022 at 10:39):

Chad Stearns (Oct 23 2022 at 03:57):

Hey @Anton @Brian Carroll . Nice to see you all. I am not on nix. When I do zig version I do see 0.9.1. I tried setting ROC_ZIG just in case and I am still seeing the same error. Looking at the error again, it is exactly the same one as Bryce's (except for the directory names of course).

Chad Stearns (Oct 23 2022 at 04:06):

Chad Stearns (Oct 23 2022 at 04:22):

/Users/chad/code/roc/target/debug/build/wasi_libc_sys-1aefd8d65824087d/out/zig-cache

Anton (Oct 23 2022 at 07:46):

Hi Chad, I'd recommend adding some dbg prints to get the necessary values and executing zig build-exe... manually from the same working dir.

Arbil (Oct 24 2022 at 05:15):

Is there a more granular command to build the roc compiler than cargo build in project root? This one builds some editor, wasm and repl stuff also

Brendan Hansknecht (Oct 24 2022 at 05:59):

Rust let's you build specific packages. Otherwise, the compiler does have some feature flags that can reduce what is pulled in, but it is pretty limited in what can be removed

Ghislain (Oct 26 2022 at 14:22):

Hi,
Yesterday I made the upgrade of MacOS to Ventura 13.0, and now my build fails :cry:
I tried cargo clean, but same output for cargo build:

bash-5.1$ RUST_BACKTRACE=1 cargo build
   Compiling roc_builtins v0.0.1 (/Users/ghigt/code/roc/source/crates/compiler/builtins)
   Compiling serde v1.0.144
   Compiling sha2 v0.10.2
   Compiling clap_derive v3.2.18
   Compiling futures-util v0.3.24
   Compiling wasm-bindgen-macro-support v0.2.83
   Compiling objc-foundation v0.1.1
   Compiling bytemuck v1.12.1
   Compiling object v0.29.0
   Compiling roc_collections v0.0.1 (/Users/ghigt/code/roc/source/crates/compiler/collections)
error: failed to run custom build command for `roc_builtins v0.0.1 (/Users/ghigt/code/roc/source/crates/compiler/builtins)`

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

  --- stderr
  thread 'main' panicked at 'zig failed: thread 333562 panic: Darwin is handled separately via std.zig.system.darwin module
  Unable to dump stack trace: debug info stripped
  ', crates/compiler/builtins/build.rs:240:21
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
     2: build_script_build::run_command
               at ./build.rs:240:21
     3: build_script_build::generate_bc_file
               at ./build.rs:133:5
     4: build_script_build::main
               at ./build.rs:40:5
     5: core::ops::function::FnOnce::call_once
               at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...

Ghislain (Oct 26 2022 at 14:27):

» 1+1
ld: warning: directory not found for option '-F/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/'
ld: library not found for -lSystem
/var/folders/y4/y9696g7j7hx_dhcfdlv9f4600000gn/T/.tmpOlm155/app.dylib: No such file or directory

Brendan Hansknecht (Oct 26 2022 at 14:28):

Ghislain (Oct 26 2022 at 14:29):

ah you're right, I currently have /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/

Ghislain (Oct 26 2022 at 14:32):

brew is telling me to upgrade to XCode 14.1 instead of 14.0.1 but it is only in RC 2 and should be released in the next days, maybe it is related and will default to MacOSX.sdk

Ghislain (Oct 26 2022 at 14:33):

Ghislain (Oct 26 2022 at 14:49):

ok, after having the /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk folder link, the previous builds work!

Ghislain (Oct 26 2022 at 14:49):

Anton (Oct 26 2022 at 15:31):

Zig has a branch up with a fix but that is for zig master, it'll probably take them some time to release 0.9.2 I suppose.

Ghislain (Oct 26 2022 at 15:59):

Thank you @Anton, so I guess we're not able to compile on MacOS Ventura until then

Ghislain (Oct 26 2022 at 16:01):

Anton (Oct 26 2022 at 16:02):

Ghislain (Oct 28 2022 at 11:04):

Would it be possible (following this answer https://github.com/ziglang/zig/issues/10478#issuecomment-1294313967) to make it run on Ventura using -target native-macos.12?
I tried with a simple hello-world.zig and it works, but I'm lost in the Roc repo to know where to put and try it

Anton (Oct 28 2022 at 11:30):

It's probably going to need to be added in multiple places. Based on the error you originally posted I would add -target native-macos.12 here to get started.

Ghislain (Oct 28 2022 at 11:33):

I tried to change this line, but without any result (I'm very new to Rust/Zig). Then I switched to build.zig but I can't find how to manage this object.

Anton (Oct 28 2022 at 11:34):

Ghislain (Oct 28 2022 at 11:37):

Ghislain (Oct 28 2022 at 11:39):

run_command(
        &bitcode_path,
        &zig_executable(),
        &[
            "build",
            zig_object,
            "-target",
            "native-macos.12",
            "-Drelease=true",
        ],
        0,
    );

Folkert de Vries (Oct 28 2022 at 11:40):

Folkert de Vries (Oct 28 2022 at 11:41):

llvm generation needs to use the right target, but probably generic macos is good enough there, then the host needs to be built with the right target, and the final linking needs to use the right target

Anton (Oct 28 2022 at 11:57):

It would probably be good to make a single zig_cmd function that is used everywhere instead of going through std::process::Command in multiple places. I'll make an issue for that.

Folkert de Vries (Oct 28 2022 at 12:00):

well, that does not always work. You need the flexibility of Command sometimes

Anton (Oct 28 2022 at 12:03):

Could the zig_cmd function not offer the same flexibility but still be centralized?

Folkert de Vries (Oct 28 2022 at 12:09):

Brian Carroll (Oct 28 2022 at 12:37):

Anoton we do lots of different things with Zig in different places. Sometimes we're compiling a host, sometimes an app, sometimes a preprocessed host, could be targeting WebAssembly or native, compiling C code or Zig code...
So it's not just the same thing duplicated all over the place. There may be some duplication but I'm skeptical we can write just one command to satisfy all these needs.

Brian Carroll (Oct 28 2022 at 12:43):

Anton (Oct 28 2022 at 12:51):

I'm aware of that, the intent is not really to avoid duplication but to have one central function that allows us to easily track where in the code base zig is used. As Folkert suggested; fn zig_cmd() -> Command would allow us to do this tracking without sacrificing any flexibility. You can still add args to the Command that gets returned.

Perhaps it makes sense to eventually go to a slightly less flexible version of fn zig_cmd() -> Command, but it is a good start.

Ghislain (Oct 28 2022 at 13:29):

Ok, so it looks out of my competence, I'll downgrade to MacOS Monterey until Roc migrate to zig 0.10.x (which looks to be released in the next 4 days)

Anton (Oct 28 2022 at 13:33):

To set expectations; I believe zig 0.10 requires us upgrading to llvm 14 which requires significant effort.

Richard Feldman (Oct 28 2022 at 13:44):

yeah if I were to guess, I'd guess we won't end up upgrading to Zig 0.10 until early 2023

Richard Feldman (Oct 28 2022 at 13:47):

mainly because we're currently focusing on Advent of Code experience (which naturally runs through December), the 0.10 upgrade isn't needed for any of that, and it's a significant project

Ghislain (Oct 28 2022 at 13:49):

Yes, I totally understand, so it's simpler - if I want to dive into the roc code and mess around with it - for me to downgrade

Ghislain (Oct 28 2022 at 17:51):

Anton (Jan 09 2023 at 17:10):

For @Arbil and others who had this issue with the vscode terminal from inside nix:
nix_vscode_terminal.png

Fred (Feb 08 2023 at 04:18):

Hi! I'm having an issue when building from source on macOS. cargo build works fine, and cargo run repl starts the repl, but when I enter anything it panics. I actually had the repl working fine when I initially set things up a few weeks ago, so I must have accidentally messed up my environment, but I can't figure out what changed. I'm using nix, and this is what happens after running cargo clean, nix develop, cargo run repl and then entering a value in the repl. Any ideas what this error is related to?

» 123
ld: unknown option: -no_fixup_chains
thread 'main' panicked at '
___________
Linking command failed with status ExitStatus(unix_wait_status(256)):

  Child { stdin: None, stdout: None, stderr: None, .. }
___________
', crates/compiler/build/src/link.rs:1464:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: roc_build::link::llvm_module_to_dylib
             at ./crates/compiler/build/src/link.rs:1464:5
   3: roc_repl_cli::cli_gen::mono_module_to_dylib
             at ./crates/repl_cli/src/cli_gen.rs:286:5
   4: roc_repl_cli::cli_gen::gen_and_eval_llvm
             at ./crates/repl_cli/src/cli_gen.rs:73:9
   5: roc_repl_cli::repl_state::ReplState::eval_and_format
             at ./crates/repl_cli/src/repl_state.rs:260:46
   6: roc_repl_cli::repl_state::ReplState::step
             at ./crates/repl_cli/src/repl_state.rs:122:46
   7: roc_repl_cli::main
             at ./crates/repl_cli/src/lib.rs:49:23
   8: roc::main
             at ./crates/cli/src/main.rs:194:35
   9: core::ops::function::FnOnce::call_once
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5

Luke Boswell (Feb 08 2023 at 06:07):

I tried it out using latest main and it seems to work for me. I'm on MacOS 12.6 using M2 silicon.

192-168-1-105:roc luke$ cargo clean
192-168-1-105:roc luke$ nix develop
192-168-1-105:roc luke$ cargo run repl
   Compiling libc v0.2.135
   []... deleted extra lines ...[]
   Compiling roc_docs v0.0.1 (/Users/luke/Documents/GitHub/roc/crates/docs)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 20s
     Running `target/debug/roc repl`

  The rockin’ roc repl
────────────────────────

Enter an expression, or :help, or :q to quit.

» 123

123 : Num *               # val1

Fred (Feb 10 2023 at 09:28):

I was able to get this working by deleting "-no_fixup_chains" from crates/compiler/build/src/link.rs line 1283! Looks like it was added in December, so must have been before that when it was working for me. I am also on MacOS 12.6 but with an intel chip by the way

choonkeat (Mar 23 2023 at 10:39):

$ cd roc
direnv: loading ~/git/roc-lang/roc/.envrc
direnv: using nix
direnv: ([/opt/homebrew/bin/direnv export zsh]) is taking a while to execute. Use CTRL-C to give up.

$ cat .envrc
use nix
PATH_add target/debug

Brendan Hansknecht (Mar 23 2023 at 15:14):

The very first time is slow. Same with calling nix develop for the first time. After that, it should be cached and fast.

Not sure about the second line though. What does it do? If it cause nix to reevaluate whenever target/debug changes, that may break caching, but i have never used the PATH_add command. So i am not truly sure.

Brendan Hansknecht (Mar 23 2023 at 15:16):

use flake
nix_direnv_watch_file rust-toolchain.toml

Brendan Hansknecht (Mar 23 2023 at 15:17):

First line at some point changed from use nix to use flake. Both should work cause our shell.nix just points to the flake. Not sure the real difference

Brendan Hansknecht (Mar 23 2023 at 15:18):

The second line is so that when I change the rust version to nightly (which I need for fuzzing and some random other times), it will force a re-evaluation

Brendan Hansknecht (Mar 23 2023 at 15:20):

Also, just looked of PATH_add, yeah, should be harmless. So probably just a matter of waiting for the first invocation that has to download and set everything up.

choonkeat (Mar 25 2023 at 02:04):

using use nix, it's slow every time (not just first time)
using use flake fails:

$ cd roc
direnv: loading ~/git/roc-lang/roc/.envrc
direnv: using flake
/bin/bash: eval:2231: conditional binary operator expected
/bin/bash: eval:2231: syntax error near `enableParallelBuilding'
/bin/bash: eval:2231: `    if ! [[ -v enableParallelBuilding ]]; then'
direnv: export +AR +AR_FOR_TARGET +AS +AS_FOR_TARGET +CC +CC_FOR_TARGET +CMAKE_FRAMEWORK_PATH +CMAKE_INCLUDE_PATH +CMAKE_LIBRARY_PATH +CMAKE_PREFIX_PATH +CONFIG_SHELL +CXX +CXX_FOR_TARGET +DETERMINISTIC_BUILD +HOST_PATH +IN_NIX_SHELL +LD +LD_DYLD_PATH +LD_FOR_TARGET +LD_LIBRARY_PATH +LLVM_SYS_130_PREFIX +MACOSX_DEPLOYMENT_TARGET +NIXPKGS_ALLOW_UNFREE +NIX_BINTOOLS +NIX_BINTOOLS_FOR_TARGET +NIX_BINTOOLS_WRAPPER_TARGET_HOST_aarch64_apple_darwin +NIX_BINTOOLS_WRAPPER_TARGET_TARGET_aarch64_apple_darwin +NIX_BUILD_CORES +NIX_CC +NIX_CC_FOR_TARGET +NIX_CC_WRAPPER_TARGET_HOST_aarch64_apple_darwin +NIX_CC_WRAPPER_TARGET_TARGET_aarch64_apple_darwin +NIX_CFLAGS_COMPILE +NIX_CFLAGS_COMPILE_FOR_TARGET +NIX_COREFOUNDATION_RPATH +NIX_DONT_SET_RPATH +NIX_DONT_SET_RPATH_FOR_BUILD +NIX_ENFORCE_NO_NATIVE +NIX_GLIBC_PATH +NIX_HARDENING_ENABLE +NIX_IGNORE_LD_THROUGH_GCC +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_LDFLAGS_FOR_TARGET +NIX_NO_SELF_RPATH +NIX_PKG_CONFIG_WRAPPER_TARGET_TARGET_aarch64_apple_darwin +NIX_STORE +NM +NM_FOR_TARGET +PATH_LOCALE +PKG_CONFIG_FOR_TARGET +PKG_CONFIG_PATH_FOR_TARGET +PYTHONHASHSEED +PYTHONNOUSERSITE +PYTHONPATH +RANLIB +RANLIB_FOR_TARGET +SIZE +SIZE_FOR_TARGET +SOURCE_DATE_EPOCH +STRINGS +STRINGS_FOR_TARGET +STRIP +STRIP_FOR_TARGET +XDG_DATA_DIRS +XML_CATALOG_FILES +__darwinAllowLocalNetworking +__impureHostDeps +__propagatedImpureHostDeps +__propagatedSandboxProfile +__sandboxProfile +__structuredAttrs +buildInputs +buildPhase +builder +cmakeFlags +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +dontAddDisableDepTrack +mesonFlags +name +nativeBuildInputs +out +outputs +patches +phases +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH

$ nix --version
nix (Nix) 2.13.3
$ direnv version
2.32.2

Brendan Hansknecht (Mar 25 2023 at 03:47):

I don't have an immediate idea. What happens when you disable direnv and run nix develop?

choonkeat (Apr 02 2023 at 04:10):

running nix develop without any direnv interference works great (i.e. cargo build works)

just to close the loop: though I'd seen the notices about old version of bash used in MacOS everywhere but somehow my mind refused to follow the trail maybe because I'm using zsh?... but whatevs, I finally brew install bash and now use flake in my .envrc works and is super fast :tada::face_palm:‍♂️

Brendan Hansknecht (Apr 02 2023 at 06:47):

Glad you found a workaround. Direnv can definitely work with zsh in Mac, but i guess it may hit whatever issue you had. Maybe the issue is with trying to load bash config into the zsh shell...no real idea.

Matthew Phillips (Dec 01 2023 at 13:28):

I'm not familiar with Cargo, is there a "clean" command I can run? Or can I just delete the target/ folder?

Richard Feldman (Dec 01 2023 at 13:30):

ZD (May 12 2024 at 04:55):

Hello, After a few tries I finally succeeded to build from source. There were warnings, but no more blocking errors. However, when I run ./target/debug/roc, I got below message.

"Target triple (aarch64-unknown-freebsd) is not currently supported by the roc compiler."

Brendan Hansknecht (May 12 2024 at 06:31):

Like probably could just be mapped to Linux or a generic Unix. I don't think anything is special about it

Stream: beginners

Topic: Building from source

Bob Shelline (Sep 14 2020 at 23:13):

Folkert de Vries (Sep 14 2020 at 23:51):

Richard Feldman (Sep 15 2020 at 00:11):

Bob Shelline (Sep 15 2020 at 14:05):

Richard Feldman (Sep 15 2020 at 14:08):

Richard Feldman (Sep 15 2020 at 14:09):

Bob Shelline (Sep 15 2020 at 14:12):

Bob Shelline (Sep 15 2020 at 14:14):

Bob Shelline (Sep 15 2020 at 14:16):

Ju Liu (Mar 26 2021 at 12:30):

Ju Liu (Mar 26 2021 at 12:30):

Anton (Mar 26 2021 at 12:35):

Ju Liu (Mar 26 2021 at 12:37):

Ju Liu (Mar 26 2021 at 12:47):

Ju Liu (Mar 26 2021 at 12:47):

Ju Liu (Mar 26 2021 at 12:48):

Ju Liu (Mar 26 2021 at 12:49):

Ju Liu (Mar 26 2021 at 12:51):

Ju Liu (Mar 26 2021 at 12:54):

Ju Liu (Mar 26 2021 at 13:06):

Anton (Mar 26 2021 at 13:16):

Anton (Mar 26 2021 at 13:25):

Anton (Mar 26 2021 at 13:25):

Peter Fields (Mar 27 2021 at 12:53):

Zeljko Nesic (Mar 27 2021 at 13:23):

Peter Fields (Mar 27 2021 at 15:30):

Anton (Mar 27 2021 at 15:39):

Folkert de Vries (Mar 28 2021 at 12:54):

Folkert de Vries (Mar 28 2021 at 12:55):

Ju Liu (Mar 28 2021 at 12:58):

Folkert de Vries (Mar 28 2021 at 13:00):

Lucas Rosa (Mar 28 2021 at 15:10):

Richard Feldman (Mar 28 2021 at 15:36):

Mario (Apr 14 2021 at 21:15):

Lucas Rosa (Apr 14 2021 at 21:53):

Lucas Rosa (Apr 14 2021 at 21:54):

Mario (Apr 14 2021 at 22:52):

Lucas Rosa (Apr 14 2021 at 23:21):

Lucas Rosa (Apr 14 2021 at 23:32):

Richard Feldman (Apr 15 2021 at 00:39):

Richard Feldman (Apr 15 2021 at 00:40):

Richard Feldman (Apr 15 2021 at 00:40):

Richard Feldman (Apr 15 2021 at 00:44):

Richard Feldman (Apr 15 2021 at 03:10):

Lucas Rosa (Apr 15 2021 at 05:43):

Mario (Apr 15 2021 at 22:31):

Mario (Apr 16 2021 at 16:36):

Tarjei Skjærset (May 13 2021 at 15:44):

Lucas Rosa (May 13 2021 at 15:52):

Lucas Rosa (May 13 2021 at 15:54):

Lucas Rosa (May 13 2021 at 15:55):

Lucas Rosa (May 13 2021 at 15:56):

Tarjei Skjærset (May 13 2021 at 15:59):

Lucas Rosa (May 13 2021 at 15:59):

Lucas Rosa (May 13 2021 at 16:00):

Tarjei Skjærset (May 13 2021 at 16:00):

Lucas Rosa (May 13 2021 at 16:00):

Lucas Rosa (May 13 2021 at 16:01):

Tarjei Skjærset (May 13 2021 at 16:02):

Lucas Rosa (May 13 2021 at 16:04):

Lucas Rosa (May 13 2021 at 16:05):

Lucas Rosa (May 13 2021 at 16:05):

Lucas Rosa (May 13 2021 at 16:06):

Tarjei Skjærset (May 13 2021 at 16:06):

Lucas Rosa (May 13 2021 at 16:08):

Tarjei Skjærset (May 13 2021 at 16:08):

Lucas Rosa (May 13 2021 at 16:08):

Lucas Rosa (May 13 2021 at 16:08):

Lucas Rosa (May 13 2021 at 16:09):

Lucas Rosa (May 13 2021 at 16:09):

Lucas Rosa (May 13 2021 at 16:09):

Tarjei Skjærset (May 13 2021 at 16:10):

Lucas Rosa (May 13 2021 at 16:10):

Lucas Rosa (May 13 2021 at 16:10):

Lucas Rosa (May 13 2021 at 16:11):

Tarjei Skjærset (May 13 2021 at 16:11):

Lucas Rosa (May 13 2021 at 16:11):

Lucas Rosa (May 13 2021 at 16:11):