Swiftaff (Sep 01 2022 at 12:52): Swiftaff (Sep 01 2022 at 12:52):Hi I'm a hobby windows developer and I'd love to help out here if I can. I'm happy to look at good first issues having coded for a few years but never contributed before! My WSL2 roc install didn't fully work and so I saw this thread and was hopeful of trying the Windows build instead. cargo build failed for me on my Windows 10.0.19044.1889 initially until I realised I needed to install Zig. It now builds as far as roc_builtins and is now erroring on "No suitable version of LLVM was found system-wide or pointed to by LLVM_SYS_130_PREFIX. Consider using llvmenv to compile an appropriate copy of LLVM, and refer to the llvm-sys documentation for more information." and wondering if you can suggest what "appropriate LLVM" would be to install to get past that or if I've missed some other step? Or, I'm also happy to persevere with linux instead if that would be more appropriate.
Folkert de Vries (Sep 01 2022 at 12:56):more people trying out windows and seeing what fails is really helpful. For llvm, the BUILDING_FROM_SOURCE.md has a section "llvm installation on windows" that you can follow
Folkert de Vries (Sep 01 2022 at 12:56):based on experience, make sure that the path you install it at does not include any spaces
Folkert de Vries (Sep 01 2022 at 12:57):the tooling does not seem to handle those well
Folkert de Vries (Sep 01 2022 at 12:59):missing from that document is setting that you need to set this variable $Env:LLVM_SYS_130_PREFIX="C:\foo\bar\LLVM-13.0.0-win64" (note no bin on the end, it must point to the folder with the llvm things)
Swiftaff (Sep 01 2022 at 12:59):OK great thanks I somehow missed the windows section as I skimmed that doc looking for instructions earlier - will give that and your notes a try!
Folkert de Vries (Sep 01 2022 at 13:00):that should get you a working cargo build I think, and you can run some of our examples that have a zig platform
Folkert de Vries (Sep 01 2022 at 13:00):other platform languages we have not tried (may be fun to see if e.g. rust works, or maybe it needs a bit of work with file names and extensions in some places)
Folkert de Vries (Sep 01 2022 at 13:01):and many tests and examples seem to segfault
Folkert de Vries (Sep 01 2022 at 13:01):if you are able to get a debugger to work on our binaries, that would be amazing
Swiftaff (Sep 01 2022 at 14:27):I'm more used to "dbg!" than debugger but see how I go later.
For now it looks like I had debug tools and VS 2019 installed, so I updated those, installed LLVM directly under C to avoid spaces in path, added that to environment path and the LLVM_SYS_130_PREFIX pointing to the root llvm folder...
...and cargo build worked!
So I tried these tests:
cargo run repl worked except thread 'main' has overflowed its stack when I entered "hello, world"
cd to /target/debug and ran roc run ../../examples/hello-world/main.roc and I get a clang error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc' ', crates\compiler\build\src\link.rs:1310:27
which seems like an unsupported windows flag? I quickly tried commenting that flag out of link.rs and rebuilding and got more errors so assume that's not an obvious fix
But I can get the basic zig example to work: https://ziglang.org/documentation/0.9.1/#Hello-World
Are these the kind of errors it should have at this stage, or do you think there are other steps I need to do first?
Swiftaff (Sep 01 2022 at 14:36):and sorry meant to say cargo check is fine, but cargo test errors at below:
error: failed to run custom build command for wasm3-sys v0.5.0 (https://github.com/roc-lang/wasm3-rs?rev=f0f807d1fc0a50d1d68e5799e54ee62c05af00f5#f0f807d1)
Caused by:
process didn't exit successfully: H:\Development\roc\target\debug\build\wasm3-sys-45856a24a6e97685\build-script-build (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to generate bindings: Error { kind: NotFound, message: "program not found" }', C:\Users\<redacted>\.cargo\git\checkouts\wasm3-rs-50bf15e0ec9610c1\f0f807d\wasm3-sys\build.rs:68:35
Folkert de Vries (Sep 01 2022 at 15:16):cargo install bindgen for that last one
Folkert de Vries (Sep 01 2022 at 15:17):for the zig clock thing, I have a PR that fixes it for the benchmarks platform https://github.com/roc-lang/roc/pull/3936
Folkert de Vries (Sep 01 2022 at 15:17):hello world uses a C platform. I wonder if maybe on windows we should use zig as the C compiler?
Folkert de Vries (Sep 01 2022 at 15:18):cargo run examples/platform-switching/zig-platform/rocLovesZig.roc should work btw
Folkert de Vries (Sep 01 2022 at 15:18):and then yes, we get lots of random segfaults (reported as stack overflows or other stuff) currently
Folkert de Vries (Sep 01 2022 at 15:19):the challenge will be to track those down, none of us have real developing native apps on windows experience
Folkert de Vries (Sep 01 2022 at 15:19):so we don't currently have the tooling/know-how to debug the problems
Swiftaff (Sep 01 2022 at 16:12):OK sorry I obviously missed that bindgen step too! - yes that worked and cargo test got through a lot more tests although crashed on a few at the end with link.exe existing code 1120 on roc_editor, roc_repository, test_derive roc_load_internal, roc_highlight, roc_glue (more out of terminal limit).
I tried applying the 6 file updates from pull 3936 but after cargo build, cargo run examples/benchmark/platform/main.roc seemed to work but did nothing until cancelled after a few minutes of inactivity, unless it takes longer than few mins to run?
Understand for hello world - I don't know really, but as zig seems to work it gets my vote
And yes rocLovesZig works!
And I see I get it now, I don't have much native Windows app experience either - I just use it as my main OS, but I'll look into setting up debugging and help where I can - and I can see if I can pick my .Net colleagues brains every now and then.
Thanks so much for your patience and help, it's an interesting project and I look forward to contrinuting more usefully as I learn! Will turn in now and take another look tomorrow after work.
Folkert de Vries (Sep 01 2022 at 16:28):main.roc is the platform file, you should run the app module rocLovesZig.roc
Folkert de Vries (Sep 01 2022 at 18:17):https://github.com/roc-lang/roc/pull/3948 has a fix that hopefully fixes some tests on windows. It has a command to run some tests. Can someone on windows run those tests and report the results?
Richard Feldman (Sep 01 2022 at 20:16):failures:
---- gen_num::to_i32_checked_larger_width_signed_fits_pos stdout ----
thread 'gen_num::to_i32_checked_larger_width_signed_fits_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d8a95aa8, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
---- gen_num::to_i32_checked_larger_width_signed_fits_neg stdout ----
thread 'gen_num::to_i32_checked_larger_width_signed_fits_neg' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d3a30a88, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_i32_checked_larger_width_signed_oob_pos stdout ----
thread 'gen_num::to_i32_checked_larger_width_signed_oob_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d0cbb4c8, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_i32_checked_larger_width_unsigned_fits_pos stdout ----
thread 'gen_num::to_i32_checked_larger_width_unsigned_fits_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d0cb8a88, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_i32_checked_larger_width_unsigned_oob_pos stdout ----
thread 'gen_num::to_i32_checked_larger_width_unsigned_oob_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d3a334c8, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_i32_checked_larger_width_signed_oob_neg stdout ----
thread 'gen_num::to_i32_checked_larger_width_signed_oob_neg' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198cfef49b8, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_i32_checked_same_width_unsigned_fits stdout ----
thread 'gen_num::to_i32_checked_same_width_unsigned_fits' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198cd4297a0, llvm_type: "i32" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_i32_checked_same_width_unsigned_oob stdout ----
thread 'gen_num::to_i32_checked_same_width_unsigned_oob' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d07254c0, llvm_type: "i32" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_larger_width_signed_fits_pos stdout ----
thread 'gen_num::to_u32_checked_larger_width_signed_fits_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d7875cc8, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_larger_width_signed_oob_neg stdout ----
thread 'gen_num::to_u32_checked_larger_width_signed_oob_neg' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198cac73d68, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_same_width_signed_oob stdout ----
thread 'gen_num::to_u32_checked_same_width_signed_oob' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198e187a500, llvm_type: "i32" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_larger_width_unsigned_oob_pos stdout ----
thread 'gen_num::to_u32_checked_larger_width_unsigned_oob_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198dfbb3798, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_same_width_signed_fits stdout ----
thread 'gen_num::to_u32_checked_same_width_signed_fits' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198e1b4fad0, llvm_type: "i32" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_larger_width_unsigned_fits_pos stdout ----
thread 'gen_num::to_u32_checked_larger_width_unsigned_fits_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198dfbb76f8, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_larger_width_signed_oob_pos stdout ----
thread 'gen_num::to_u32_checked_larger_width_signed_oob_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198e1878568, llvm_type: "i64" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_smaller_width_neg_oob stdout ----
thread 'gen_num::to_u32_checked_smaller_width_neg_oob' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198cd6001e0, llvm_type: "i8" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
---- gen_num::to_u32_checked_smaller_width_pos stdout ----
thread 'gen_num::to_u32_checked_smaller_width_pos' panicked at 'Found IntType(IntType { int_type: Type { address: 0x198d9898fa0, llvm_type: "i8" } }) but expected the PointerType variant', C:\Users\Richard Feldman\.cargo\git\checkouts\inkwell-55729a4c43239568\accd406\src\types\enums.rs:398:13
failures:
gen_num::to_i32_checked_larger_width_signed_fits_neg
gen_num::to_i32_checked_larger_width_signed_fits_pos
gen_num::to_i32_checked_larger_width_signed_oob_neg
gen_num::to_i32_checked_larger_width_signed_oob_pos
gen_num::to_i32_checked_larger_width_unsigned_fits_pos
gen_num::to_i32_checked_larger_width_unsigned_oob_pos
gen_num::to_i32_checked_same_width_unsigned_fits
gen_num::to_i32_checked_same_width_unsigned_oob
gen_num::to_u32_checked_larger_width_signed_fits_pos
gen_num::to_u32_checked_larger_width_signed_oob_neg
gen_num::to_u32_checked_larger_width_signed_oob_pos
gen_num::to_u32_checked_larger_width_unsigned_fits_pos
gen_num::to_u32_checked_larger_width_unsigned_oob_pos
gen_num::to_u32_checked_same_width_signed_fits
gen_num::to_u32_checked_same_width_signed_oob
gen_num::to_u32_checked_smaller_width_neg_oob
gen_num::to_u32_checked_smaller_width_pos
test result: FAILED. 149 passed; 17 failed; 0 ignored; 0 measured; 938 filtered out; finished in 22.65s
Richard Feldman (Sep 01 2022 at 20:16):that was on Windows 11
Swiftaff (Sep 02 2022 at 15:21):FYI on Windows 10 I got the same result after pulling 3948 - plus these additional 5 failures:
---- gen_num::to_f32_from_i64 stdout ----
thread 'gen_num::to_f32_from_i64' panicked at 'Error loading compiled dylib for test: LoadLibraryExW { source: Os { code: 193, kind: Uncategorized, message: "%1 is not a valid Win32 application." } }', crates\compiler\test_gen\src\helpers\llvm.rs:324:23
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
---- gen_num::to_f32_from_f64 stdout ----
thread 'gen_num::to_f32_from_f64' panicked at 'Error loading compiled dylib for test: LoadLibraryExW { source: Os { code: 193, kind: Uncategorized, message: "%1 is not a valid Win32 application." } }', crates\compiler\test_gen\src\helpers\llvm.rs:324:23
---- gen_num::to_f32_from_f32 stdout ----
thread 'gen_num::to_f32_from_f32' panicked at 'Error loading compiled dylib for test: LoadLibraryExW { source: Os { code: 193, kind: Uncategorized, message: "%1 is not a valid Win32 application." } }', crates\compiler\test_gen\src\helpers\llvm.rs:324:23
---- gen_num::to_f32_from_i16 stdout ----
thread 'gen_num::to_f32_from_i16' panicked at 'Error loading compiled dylib for test: LoadLibraryExW { source: Os { code: 193, kind: Uncategorized, message: "%1 is not a valid Win32 application." } }', crates\compiler\test_gen\src\helpers\llvm.rs:324:23
---- gen_num::to_f32_from_i128 stdout ----
thread 'gen_num::to_f32_from_i128' panicked at 'Error loading compiled dylib for test: LoadLibraryExW { source: Os { code: 193, kind: Uncategorized, message: "%1 is not a valid Win32 application." } }', crates\compiler\test_gen\src\helpers\llvm.rs:324:23
Swiftaff (Sep 02 2022 at 15:28):Aaand just tried running the test a few more times and those extra 5 no longer error!
Swiftaff (Sep 02 2022 at 16:57):Folkert de Vries said:
if you are able to get a debugger to work on our binaries, that would be amazing
I've just experimented after googling debugging .EXEs https://devblogs.microsoft.com/visualstudio/how-to-debug-and-profile-any-exe-with-visual-studio/ and ran a simple example through the Visual Studio 2019 debugger by debugging the '/target/debug/roc.exe' with 'repl' argument - since the repl always stack overflows for me after any command. The exception breakpoint stopped at the next statement to execute on 'roc\crates\compiler\constrain\src\expr.rs' at 'pub fn constrain_expr(' with this call stack... frankly I'm a bit out of my depth here - but happy to keep plugging away tomorrow onwards in the absence of anyone with more experience - if you have ideas on what I can look for
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 174 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 362 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 389 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 389 Unknown
roc.exe!roc_constrain::expr::constrain_field(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_types::subs::Variable field_var, roc_region::all::Loc<enum$<roc_can::expr::Expr>> * loc_expr) Line 1980 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 205 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 389 Unknown
roc.exe!roc_constrain::expr::constrain_def(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_can::def::Def * def, enum$<roc_can::constraint::Constraint> body_con) Line 2623 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 1037 Unknown
[Inline Frame] roc.exe!roc_constrain::expr::constrain_when_branch_help(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region when_branch, roc_can::expr::WhenBranch * expr_expected, roc_constrain::expr::constrain_expr::closure_env$5) Line 1869 Unknown
roc.exe!roc_constrain::expr::constrain_expr(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_region::all::Region expr, enum$<roc_can::expr::Expr> * expected, enum$<roc_can::expected::Expected<enum$<roc_types::types::Type>>>) Line 804 Unknown
roc.exe!roc_constrain::expr::constrain_function_def(roc_can::constraint::Constraints * constraints, roc_constrain::expr::Env * env, roc_can::expr::Declarations * declarations, unsigned __int64 index, roc_collections::soa::Index<roc_region::all::Loc<roc_can::expr::FunctionDef>> function_def_index, enum$<roc_can::constraint::Constraint> body_con) Line 1561 Unknown
[Inline Frame] roc.exe!roc_constrain::expr::constrain_decls(roc_can::constraint::Constraints * constraints, roc_module::symbol::ModuleId home, roc_can::expr::Declarations * declarations) Line 2065 Unknown
roc.exe!roc_constrain::module::constrain_module(roc_can::constraint::Constraints * constraints, alloc::vec::Vec<tuple$<roc_region::all::Loc<roc_module::symbol::Symbol>,roc_region::all::Loc<enum$<roc_types::types::Type>>>,alloc::alloc::Global> symbols_from_requires, roc_can::abilities::IAbilitiesStore<roc_can::abilities::Pending> * abilities_store, roc_can::expr::Declarations * declarations, roc_module::symbol::ModuleId home) Line 18 Unknown
roc.exe!roc_load_internal::file::canonicalize_and_constrain(bumpalo::Bump * arena, roc_module::symbol::ModuleIds * module_ids, roc_module::symbol::IdentIdsByModule dep_idents, roc_collections::vec_set::VecSet<roc_module::symbol::Symbol> exposed_symbols, std::collections::hash::map::HashMap<roc_module::symbol::Symbol,roc_types::types::Alias,core::hash::BuildHasherDefault<wyhash::traits::WyHash>> aliases, roc_can::abilities::IAbilitiesStore<roc_can::abilities::Pending> imported_abilities_state, roc_load_internal::file::ParsedModule parsed, bool skip_constraint_gen) Line 4594 Unknown
roc.exe!roc_load_internal::file::run_task(enum$<roc_load_internal::file::BuildTask> task, bumpalo::Bump * arena, ref$<std::path::Path>) Line 5415 Unknown
roc.exe!roc_load_internal::file::worker_task_step(bumpalo::Bump * worker_arena, crossbeam_deque::deque::Worker<enum$<roc_load_internal::file::BuildTask>> * worker, crossbeam_deque::deque::Injector<enum$<roc_load_internal::file::BuildTask>> * injector, slice$<crossbeam_deque::deque::Stealer<enum$<roc_load_internal::file::BuildTask>>> worker_msg_rx, crossbeam_channel::channel::Receiver<roc_load_internal::file::WorkerMsg> * msg_tx, crossbeam_channel::channel::Sender<enum$<roc_load_internal::file::Msg>> *) Line 1881 Unknown
roc.exe!roc_load_internal::file::load_single_threaded(bumpalo::Bump * arena, roc_load_internal::file::LoadStart load_start, roc_can::module::ExposedByModule exposed_types, roc_target::TargetInfo cached_subs, std::collections::hash::map::HashMap<roc_module::symbol::ModuleId,tuple$<roc_types::subs::Subs,alloc::vec::Vec<tuple$<roc_module::symbol::Symbol,roc_types::subs::Variable>,alloc::alloc::Global>>,core::hash::BuildHasherDefault<wyhash::traits::WyHash>> render, roc_reporting::report::RenderTarget exec_mode, roc_load_internal::file::ExecutionMode) Line 1542 Unknown
roc.exe!roc_load_internal::file::load(bumpalo::Bump * arena, roc_load_internal::file::LoadStart load_start, roc_can::module::ExposedByModule exposed_types, std::collections::hash::map::HashMap<roc_module::symbol::ModuleId,tuple$<roc_types::subs::Subs,alloc::vec::Vec<tuple$<roc_module::symbol::Symbol,roc_types::subs::Variable>,alloc::alloc::Global>>,core::hash::BuildHasherDefault<wyhash::traits::WyHash>> cached_subs, roc_load_internal::file::LoadConfig load_config) Line 1459 Unknown
roc.exe!roc_load::load(bumpalo::Bump * arena, roc_load_internal::file::LoadStart load_start, roc_can::module::ExposedByModule exposed_types, roc_load_internal::file::LoadConfig load_config) Line 32 Unknown
roc.exe!roc_load::load_and_monomorphize_from_str(bumpalo::Bump * arena, std::path::PathBuf filename, str src_dir, std::path::PathBuf exposed_types, roc_can::module::ExposedByModule load_config, roc_load_internal::file::LoadConfig) Line 93 Unknown
roc.exe!roc_repl_eval::gen::compile_to_mono(bumpalo::Bump * arena, str palette, roc_target::TargetInfo) Line 57 Unknown
roc.exe!roc_repl_cli::gen_and_eval_llvm(str target, target_lexicon::triple::Triple opt_level, roc_mono::ir::OptLevel) Line 305 Unknown
roc.exe!roc_repl_cli::eval_and_format(str) Line 367 Unknown
roc.exe!roc_repl_cli::main() Line 433 Unknown
roc.exe!roc::main() Line 176 Unknown
roc.exe!core::ops::function::FnOnce::call_once<enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err> ()(),tuple$<>>(enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>()()) Line 227 Unknown
roc.exe!std::sys_common::backtrace::__rust_begin_short_backtrace<enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err> ()(),enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>>(enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>()() f) Line 122 Unknown
roc.exe!std::rt::lang_start::closure$0<enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>>(std::rt::lang_start::closure_env$0<enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>> *) Line 145 Unknown
[Inline Frame] roc.exe!core::ops::function::impls::impl$2::call_once() Line 259 Unknown
[Inline Frame] roc.exe!std::panicking::try::do_call() Line 492 Unknown
[Inline Frame] roc.exe!std::panicking::try() Line 456 Unknown
[Inline Frame] roc.exe!std::panic::catch_unwind() Line 137 Unknown
[Inline Frame] roc.exe!std::rt::lang_start_internal::closure$2() Line 128 Unknown
[Inline Frame] roc.exe!std::panicking::try::do_call() Line 492 Unknown
[Inline Frame] roc.exe!std::panicking::try() Line 456 Unknown
[Inline Frame] roc.exe!std::panic::catch_unwind() Line 137 Unknown
roc.exe!std::rt::lang_start_internal() Line 128 Unknown
roc.exe!std::rt::lang_start<enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>>(enum$<core::result::Result<tuple$<>,std::io::error::Error>, 1, 18446744073709551615, Err>(*)() main, __int64 argc, unsigned char * * argv) Line 144 Unknown
[External Code]
Folkert de Vries (Sep 02 2022 at 17:19):based on that output it might actually be a stack overflow
Folkert de Vries (Sep 02 2022 at 17:19):meaning we'd need to increase how much stack space is allowed
Folkert de Vries (Sep 02 2022 at 17:20):for those number errors, I kind of need a full backtrace
Folkert de Vries (Sep 02 2022 at 17:20):so $env:RUST_BACKTRACE=1 or something and then run just one of the failing tests again
Folkert de Vries (Sep 02 2022 at 17:50):another one, Could someone on windows try https://github.com/roc-lang/roc/pull/3950 with cargo test-gen-llvm gen_dict and report any errors
Anton (Sep 02 2022 at 18:06):running it now...
Anton (Sep 02 2022 at 18:09): Folkert de Vries (Sep 02 2022 at 18:12):maybe try just one of them?
Folkert de Vries (Sep 02 2022 at 18:12):there is a lot of noise
Folkert de Vries (Sep 02 2022 at 18:13):gen_dict::insert_all_prefer_first maybe
Folkert de Vries (Sep 02 2022 at 18:38):and we made some improvements to installing the dependencies on windows. https://github.com/roc-lang/roc/pull/3953 please leave a review comment if you have further suggestions
Swiftaff (Sep 03 2022 at 07:18):I replied with my test results in pull/3948 & pull/3950
Folkert de Vries (Sep 03 2022 at 10:42):thanks! I made some changes to 3948, can you try it again?
Swiftaff (Sep 03 2022 at 15:33):yup the 3948 tests all pass for me now!
cargo test-gen-llvm gen_num::to_
test result: ok. 166 passed; 0 failed; 0 ignored; 0 measured; 944 filtered out; finished in 137.87s
Folkert de Vries (Sep 04 2022 at 17:06):another set of fixes https://github.com/roc-lang/roc/pull/3965
based on the llvm IR gen, cargo test-gen-llvm gen_num should now be able to run all tests. please report any that fail
Swiftaff (Sep 05 2022 at 10:59):Almost! but fails for me on looks like just the last 2 asserts of these 2 tests with exactly the same error like this but different test name...
num_to_str_f32
num_to_str_f64
Caused by:
process didn't exit successfully: H:\Development\roc\target\debug\deps\test_gen-981323e19142b58c.exe gen_num::num_to_str_f64 --exact --nocapture (exit code: 0xc0000374, STATUS_HEAP_CORRUPTION)
Also - I asume it's expected for most tests to say 'warning: ignoring debug info with an invalid version (0) in app'?
Folkert de Vries (Sep 05 2022 at 11:03):ok, those test failures make sense
Folkert de Vries (Sep 05 2022 at 11:03):for some reason that we don't yet understand, whenever we return a pointer from roc to rust, that segfaults on windows
Folkert de Vries (Sep 05 2022 at 11:04):and re the "warning: ignoring ..." that is something thatLLVM prints and I don't know why. Kind of hoping it goes away with zig 0.10
Folkert de Vries (Sep 09 2022 at 21:22):Richard and I got the llvm gen tests to work https://github.com/roc-lang/roc/pull/4003 by just ignoring 3 tests (they all use roc_panic, so something is up there)
Folkert de Vries (Sep 09 2022 at 21:23):and by leaking memory allocated in a DLL (not 100% sure what's going on there, but this at least makes the tests run)
Folkert de Vries (Sep 09 2022 at 21:23):@Anton that means that the windows CI can not only build, but also run some tests (gen for llvm and wasm, and also parse and format tests already work)
Ayaz Hafiz (Sep 09 2022 at 21:46):For the tests that should panic and fail, I bet it's a problem with the setjmp/longjmp stuff. We had to patch that when making it work for M1 a few months ago as well.
Richard Feldman (Sep 09 2022 at 23:27):lots of the panics do work though... :thinking:
Richard Feldman (Sep 09 2022 at 23:27):er, lots of the tests with panics
Anton (Sep 10 2022 at 07:11):Awesome, I hope to tackle the lld-link build issue on the windows CI machine today, after that I'll add testing.
Folkert de Vries (Sep 18 2022 at 19:45):if someone on windows wants to run this app.exe and see what happens, that might be helpful. I expect it to crash, but hopefully it tells more than wine does
Folkert de Vries (Sep 18 2022 at 19:46):it's the current state of the surgical linker on windows with a trivial (non-roc) app and host.
Folkert de Vries (Sep 18 2022 at 19:47):it's close to working, but not quite there yet and now we're in the tedious debugging phase
Brian Carroll (Sep 18 2022 at 20:05):PS C:\Users\Brian\Downloads> .\app.exe
Program 'app.exe' failed to run: The specified executable is not a valid application for this OS platform.At line:1
char:1
+ .\app.exe
+ ~~~~~~~~~.
At line:1 char:1
+ .\app.exe
+ ~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException
+ FullyQualifiedErrorId : NativeCommandFailed
If I run it in a cmd shell rather than Powershell, I get a popup window saying "This app can't run on your PC. To find a version for your PC, check with the software publisher"
Folkert de Vries (Sep 18 2022 at 20:11):well...
Brian Carroll (Sep 18 2022 at 20:11):x86_64 machine running Windows 11 Home, version 21H2, build 22000.856
Folkert de Vries (Sep 18 2022 at 20:11):thanks for trying, but the error message quality here is not great ...
Brian Carroll (Sep 18 2022 at 20:12):Yep
Folkert de Vries (Sep 18 2022 at 20:12):must mean something is malformed in practice. the .exe is syntactically valid, but semantically something must be fundamentally wrong
Brian Carroll (Sep 18 2022 at 20:13):yeah
Folkert de Vries (Sep 18 2022 at 20:21):ok, seems like I can make some progress by using a host.exe that we did not touch (i.e. we didn't reserve any sections in it)
Folkert de Vries (Sep 18 2022 at 20:21):I then remove the references to the dylib, and get
wine: Unhandled page fault on execute access to 0000000100003A20 at address 0000000100003A20 (thread 002b), starting debugger...
Unhandled exception: page fault on execute access to 0x100003a20 in 64-bit code (0x0000000100003a20).
Register dump:
rip:0000000100003a20 rsp:000000000112f9f8 rbp:000000000112fa20 eflags:00010246 ( R- -- I Z- -P- )
rax:0000000000000001 rbx:0000000000000001 rcx:000000000000002a rdx:00000000011313f0
rsi:00000000012d0810 rdi:0000000000000067 r8:00000000012d0810 r9:0000000000000020 r10:0000000000000003
r11:0000000000000246 r12:0000000000000000 r13:0000000000000000 r14:00000000011313f0 r15:0000000000000001
which I'm pretty sure is because the function that the app is supposed to expose to the host is not hooked up correctly
Folkert de Vries (Sep 18 2022 at 20:22):so it's trying to execute stuff on a page that is not executable
Folkert de Vries (Sep 18 2022 at 20:52):does hostapp.exe do anything more interesting? based on the debugger it gets past the calls to our dynamic functions, but then runs into a page that is not marked as executable ?!
Brian Carroll (Sep 18 2022 at 21:00):No output at all but it returns an error code, which apparently you can retrieve by printing an env variable
C:\Users\Brian\Downloads>.\hostapp.exe
C:\Users\Brian\Downloads>echo %ERRORLEVEL%
-1073741819
it is supposed to return a non-standard error code
Folkert de Vries (Sep 18 2022 at 21:02):so I think that's good?
Folkert de Vries (Sep 18 2022 at 21:04):it should return 192u8 though
Brian Carroll (Sep 18 2022 at 21:04):yeah that number is way too big I think
Folkert de Vries (Sep 18 2022 at 21:05):not sure what the problem could be at this point though
Folkert de Vries (Sep 18 2022 at 21:14):I guess this is where a debugger would be helpful?
Brian Carroll (Sep 18 2022 at 21:20):Yeah this runs in Visual Studio debugger, whereas app.exe didn't.
Exception thrown at 0x00007FF600001AA6 in hostapp.exe: 0xC0000005: Access violation executing location 0x00007FF600001AA6.
Call stack:
Name Language
00007ff600001aa6() Unknown
hostapp.exe!00007ff61c7b1062() Unknown
hostapp.exe!00007ff61c7b146a() Unknown
hostapp.exe!00007ff61c7b14c6() Unknown
kernel32.dll!00007fff41e654e0() Unknown
ntdll.dll!00007fff42e0485b() Unknown
So I guess there are no debug symbols in the file?
Folkert de Vries (Sep 18 2022 at 21:22):right, I can add them add them though
Brian Carroll (Sep 18 2022 at 21:23):I can see the disassembly, and look at those locations in the call stack.
the one where it throws only shows ??? for the disassembly but the other two in hostapp.exe look like normal x64 assembly code
Brian Carroll (Sep 18 2022 at 21:23):so I guess it jumped somewhere invalid
Folkert de Vries (Sep 18 2022 at 21:25):for me it now shows
Segmentation fault at address 0x10005c3e6
???:?:?: 0x10005c3e6 in ??? (???)
/home/folkertdev/Downloads/zig-linux-x86_64-0.9.1/lib/std/start.zig:558:29: 0x1400039ee in std.start.callMain (host.obj)
thread 43 panic: reached unreachable code
/home/folkertdev/Downloads/zig-linux-x86_64-0.9.1/lib/std/os/windows.zig:114:33: 0x14003face in std.os.windows.OpenFile (host.obj)
Panicked during a panic. Aborting.
wine: Unhandled exception 0x80000003 in thread 2b at address 000000014000217A (thread 002b), starting debugger...
0x000000014000217a std.os.abort+0xa in hostapp: int $3
In visual studio I get the same as before. Call stack is still hex addresses, not proper names.
Brian Carroll (Sep 18 2022 at 21:30):but call stack is now deeper
Brian Carroll (Sep 18 2022 at 21:31):6 hostapp frames instead of 3
Folkert de Vries (Sep 18 2022 at 21:31):but, the problem to me seems to be outside of main
Folkert de Vries (Sep 18 2022 at 21:33):these are the two calls to the linked-in functions
140001ddc: e8 87 f1 05 00 call 0x140060f68
140001de1: 88 45 fd mov BYTE PTR [rbp-0x3],al
140001de4: 31 c9 xor ecx,ecx
140001de6: e8 75 f1 05 00 call 0x140060f60
140001deb: 88 c1 mov cl,al
140001ded: 8a 45 fd mov al,BYTE PTR [rbp-0x3]
140001df0: 00 c8 add al,cl
hmm, 0x10005c3e6 is outside of the actual text section
Folkert de Vries (Sep 18 2022 at 21:39):or is it? I mean the address in Segmentation fault at address 0x10005c3e6
SECTION HEADER #1
.text name
5bfda virtual size
1000 virtual address
5c000 size of raw data
400 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
CNT_CODE
MEM_EXECUTE
MEM_READ
hmm that does not even make sense, because the whole app is loaded at 0x140000000
Folkert de Vries (Sep 18 2022 at 21:52):ah, progress. There is a problem with calling the functions that originally came from the dynamic lib. When I add a branch (switching on a random number to fool the optimizer) and the functions are not called, the program runs correctly
Folkert de Vries (Sep 18 2022 at 21:52):so it must be that I don't actually understand (fully) how to fix the calls
Folkert de Vries (Sep 19 2022 at 08:01):I got this to work
> wine64 hostapp.exe
Hello, 42!
it links these zig objects
// host
const std = @import("std");
extern fn double() callconv(.C) u64;
pub fn main() !void {
const stdout = std.io.getStdOut().writer();
try stdout.print("Hello, {}!\n", .{double()});
}
// app
export fn double() u64 {
return 42;
}
with the surgical linking approach and IT WORKS!
Folkert de Vries (Sep 19 2022 at 08:10):(the only cheaty bit is that I copied the app assembly manually, but that is acceptable for now I think)
Folkert de Vries (Sep 19 2022 at 08:53):code https://github.com/roc-lang/roc/pull/4065
Richard Feldman (Sep 19 2022 at 14:01):wooooooooo!!!!!!
Folkert de Vries (Sep 30 2022 at 22:16):I'm hitting
warning: `roc_linker` (lib) generated 2 warnings
Finished dev [unoptimized + debuginfo] target(s) in 1.65s
Running `target\debug\roc.exe .\examples\platform-switching\rocLovesZig.roc`
🔨 Rebuilding platform...
warning: ignoring debug info with an invalid version (0) in app
thread '<unnamed>' panicked at 'Failed to rebuild host.zig - stderr of the `zig` command was:
error(compilation): clang failed with stderr: zig: error: unable to make temporary file: No such file or directory
error(compilation): clang failed with stderr: zig: error: unable to make temporary file: No such file or directory
error(compilation): clang failed with stderr: zig: error: unable to make temporary file: No such file or directory
...
error(compilation): C:\Users\folkert\Downloads\zig-windows-x86_64-0.9.1\lib\libc\mingw\math\x86\remquo.S:1:1: unable to build C object: clang exit
ed with code 1
error(compilation): C:\Users\folkert\Downloads\zig-windows-x86_64-0.9.1\lib\libc\mingw\math\x86\truncf.S:1:1: unable to build C object: clang exit
ed with code 1
on windows. It feels familiar, but I don't remember how to fix it
Brendan Hansknecht (Sep 30 2022 at 22:45):Something with the zig cache folder?
Folkert de Vries (Oct 18 2022 at 17:50):Could someone on windows run on the refine-relocation-location branch
cargo run -- --linker=surgical crates/cli_testing_examples/platform-switching/rocLovesZig.roc
I _think_ this should work. On my machine using this cargo run fails, but manually running the produced executable succeeds.
I get a mingw error here
https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-crt/crt/pseudo-reloc.c#L195
this is very odd, maybe something is wrong with the memexec crate but @Brian Carroll and I verified on one point that it worked on his machine.
Folkert de Vries (Oct 18 2022 at 17:54):it does actually work when you explicitly pass --linker=legacy, so I guess there is still a bug in the surgical linker somewhere that neither wine nor a windows shell catches, but mingw does
Brian Carroll (Oct 18 2022 at 18:11):I will run it on my machine later, but need to go out for a couple of hours now.
Luke Boswell (Oct 18 2022 at 19:40):I get this error when I run it. error.log
Folkert de Vries (Oct 18 2022 at 21:11):hmm, yes, can you try commenting this -fPIE line?
if let Some(shared_lib_path) = shared_lib_path {
command.args(&[
"build-exe",
// "-fPIE", PIE seems to fail on windows
in crates/compiler/build/src/link.rs
Folkert de Vries (Oct 18 2022 at 21:11):I'm pretty sure PIE is just not a thing on windows, the C compiler just won't do it
Brian Carroll (Oct 18 2022 at 21:27):Even without PIE, I still get
'called `Result::unwrap()` on an `Err` value: Any { .. }', crates\cli\src\build.rs:307:46
As well as the -fPIE I also tried getting rid of -pie, which could be unrelated and just sound similar! But same panic.
Brian Carroll (Oct 18 2022 at 21:34):Yeah from Googling around it seems that Windows achieves position independence by doing relocations when the executable is loaded.
Luke Boswell (Oct 18 2022 at 21:35):FYI cargo build --release --locked works now and gives me a working roc.
Luke Boswell (Oct 18 2022 at 21:39):I'm not sure if that is revelant information, but trying to use roc run on helloWorld.roc gives me this error.log gist
Luke Boswell (Oct 18 2022 at 21:49):roc repl seems to be working ok.
Screenshot-2022-10-19-084846.jpg
Folkert de Vries (Oct 18 2022 at 22:10):only zig platforms would work right now
Folkert de Vries (Oct 18 2022 at 22:11):for rust I think we'd need some compiler infra (cause some C is involved there), but also the cli platform is not currently written to be usable on windows, so that would need some work I'd guess (don't know how platform-specific it really is)
Folkert de Vries (Oct 18 2022 at 22:12):@Brian Carroll does it now show more than that? that panic is when the host rebuild thread failed, that is a weird error in this case
Folkert de Vries (Oct 18 2022 at 22:13):and the problem I was having indeed seems like something with program loading that mingw does not do in my case. I suspect something in the binary is not quite right for that to work. But it does work in wine/powershell so most of the structure of the binary is correct
Brian Carroll (Oct 19 2022 at 06:42):Folkert de Vries said:
Brian Carroll does it now show more than that? that panic is when the host rebuild thread failed, that is a weird error in this case
Yeah tons more. I skipped as I thought it was the same as others had posted but apparently it's not. The first few lines mention a directory that doesn't exist, that Zig seems to be trying to write a temporary file into. But I don't know where that would be. Maybe the zig cache?
errors.tmp
Brian Carroll (Oct 19 2022 at 06:59):No, if I delete crates\cli_testing_examples\platform-switching\zig-platform\zig-cache and rerun the cargo run command, it is recreated with stuff inside it.
Folkert de Vries (Oct 19 2022 at 10:12):yes this is because of that -fPIE flag
Folkert de Vries (Oct 19 2022 at 10:12):or it should be... it is for me
Brian Carroll (Oct 19 2022 at 12:29):Hmmm... I'm on your branch, which has that commented out already, but I still get the error.
Here is the output of dbg!(&command). You can see there is no -fPIE.
[crates\compiler\build\src\link.rs:236] &command = "zig" "build-exe" "crates\\cli_testing_examples\\platform-switching\\zig-platform\\libapp.obj" "C:\\Users\\Brian\\Documents\\GitHub\\roc\\target\\debug\\lib\\builtins-windows-x86_64.obj" "crates\\cli_testing_examples\\platform-switching\\zig-platform\\host.zig" "-femit-bin=crates\\cli_testing_examples\\platform-switching\\zig-platform\\dynhost.exe" "--pkg-begin" "str" "C:\\Users\\Brian\\Documents\\GitHub\\roc\\target\\debug\\lib\\str.zig" "--pkg-end" "--library" "c" "-dynamic" "-target" "x86_64-windows-gnu"
hmm, that is very strange
Folkert de Vries (Oct 19 2022 at 12:39):and I guess using roc build instead produces the same thing?
Brian Carroll (Oct 19 2022 at 12:42):yes
Folkert de Vries (Oct 19 2022 at 12:46):so what if you just run the zig command, that still fails?
Folkert de Vries (Oct 19 2022 at 12:46):in your own shell I mean
Brian Carroll (Oct 19 2022 at 17:38):That works yeah! I had to put quotes around the path to dynhost.exe but when I did, no crash output
zig build-exe crates\cli_testing_examples\platform-switching\zig-platform\libapp.obj C:\Users\Brian\Documents\GitHub\roc\target\debug\lib\builtins-windows-x86_64.obj crates\cli_testing_examples\platform-switching\zig-platform\host.zig -femit-bin="crates\cli_testing_examples\platform-switching\zig-platform\dynhost.exe" --pkg-begin str C:\Users\Brian\Documents\GitHub\roc\target\debug\lib\str.zig --pkg-end --library c -dynamic -target x86_64-windows-gnu
so, the way we build up the Command is the problem here? can you play around with that a bit maybe?
Brian Carroll (Oct 19 2022 at 20:47):Ok. I can have a look tomorrow morning
Brian Carroll (Oct 20 2022 at 06:03):I don't think it's about how we build the command. I got it to work once and now it works every time. It's like some file or directory was created and now that it's there, everything is fine. But I don't know where! I have tried deleting libapp.obj and dynhost.exe but it still works fine.
Brian Carroll (Oct 20 2022 at 06:03):The original error mentioned something about Zig trying to write a temporary file somewhere so I also deleted the zig-cache but that didn't reproduce the error either
Brian Carroll (Oct 20 2022 at 06:06):OK if I delete Zig's global cache dir and retry the cargo run command, it crashes.
Brian Carroll (Oct 20 2022 at 06:07):I found and deleted it like this:
PS C:\Users\Brian> zig env
{
"zig_exe": "C:\\Users\\Brian\\zig-windows-x86_64-0.9.1\\zig.exe",
"lib_dir": "C:\\Users\\Brian\\zig-windows-x86_64-0.9.1\\lib",
"std_dir": "C:\\Users\\Brian\\zig-windows-x86_64-0.9.1\\lib\\std",
"global_cache_dir": "C:\\Users\\Brian\\AppData\\Local\\zig",
"version": "0.9.1"
}
PS C:\Users\Brian> del "C:\\Users\\Brian\\AppData\\Local\\zig"
ok, that's wild
Folkert de Vries (Oct 20 2022 at 07:01):and then adding some quotes to the command somehow fixes that?
Folkert de Vries (Oct 20 2022 at 07:01):btw when it works, what does roc run do?
Brian Carroll (Oct 20 2022 at 09:45):No, when I let Rust do the command there is never any issue with quotes. Only when I manually enter the command into PowerShell I need to quote the dynhost.exe path or it gets upset about the .exe.
So I think we can forget about the quotes issue.
Brian Carroll (Oct 20 2022 at 09:47):If you delete the zig global cache do you see the same thing?
Folkert de Vries (Oct 20 2022 at 09:57):yes, actually
Folkert de Vries (Oct 20 2022 at 09:57):so the way to fix that is to run in your own shell literally the thing that the rust program runs, and then it works?!
Brian Carroll (Oct 20 2022 at 11:04):Apparently, yeah! Not the slickest solution :joy:
Brian Carroll (Oct 20 2022 at 11:05):I wonder if there's some environment variables that are different when Rust runs it
Folkert de Vries (Oct 20 2022 at 11:26):could it be the same mingw thing?
Folkert de Vries (Oct 20 2022 at 18:05):hmm, running the zig command by itself does not fix compilation for me. That's unfortunate because now nothing works...
Folkert de Vries (Oct 20 2022 at 18:05):in fact, the zig just errors because it can't find certain dlls
Folkert de Vries (Oct 21 2022 at 12:36):I think I figured out the cause: the local zig-cache and the global one got out of sync.
Folkert de Vries (Oct 21 2022 at 12:36):which you can fix by removing both and then re-building
Folkert de Vries (Oct 21 2022 at 12:37):so idk, maybe either one of them got corrupted on your system (maybe using a newer/older zig version?) and then you get that error
Folkert de Vries (Nov 10 2022 at 18:15):does someone know how to get the equivalent of ~/.cargo on windows? I tried some stuff with %HOMEPATH% but that does not get expanded
Brian Carroll (Nov 10 2022 at 18:21):Try %APPDATA%. I think it usually expands to c:\Users\Username\Appdata\Roaming
Salman Shaik (Nov 11 2022 at 04:30):$home
Folkert de Vries (Nov 11 2022 at 23:17):how do I remove this prefix here
use std::path::Path;
fn main() {
let path = Path::new("\\\\?\\C:\\Users\\folkert\\Documents\\GitHub\\roc\\target\\debug\\roc.exe");
dbg!(path.starts_with("\\\\?\\"));
}
paths on windows: maddening
Folkert de Vries (Nov 11 2022 at 23:17):that debug print returns false by the way
Folkert de Vries (Nov 11 2022 at 23:19):because the fun thing is, such paths don't actually work in powershell
Folkert de Vries (Nov 11 2022 at 23:25):seems like there is just no good way to do this? https://stackoverflow.com/questions/50322817/how-do-i-remove-the-prefix-from-a-canonical-windows-path
Folkert de Vries (Nov 11 2022 at 23:27):@Anton this breaks any use of the utils::get_lib_path function, because these paths are just unusable when doing a Command
Folkert de Vries (Nov 11 2022 at 23:51):I have a super hacky fix here https://github.com/roc-lang/roc/compare/csv-parser-zig
Luke Boswell (Dec 21 2024 at 04:34):@Brendan Hansknecht or anyone...
Just testing a new build of Windows and have discovered that building with --optimize is now failing with non-zero exit code. Did we make any changes that might be related?
I'm guessing the llvm-zig upgrade is up there as a candidate. I don't suppose anyone else is using Windows and would have noticed.
PS C:\Users\bosyl\Documents\GitHub\roc-ray> .\windows\bin\roc.exe build --no-link --output=app.obj .\examples\basic-shapes.roc
0 errors and 0 warnings found in 535 ms while successfully building:
app.obj
PS C:\Users\bosyl\Documents\GitHub\roc-ray> .\windows\bin\roc.exe build --no-link --optimize --output=app.obj .\examples\basic-shapes.roc
Yeah, I would guess the zig and llvm upgrade
Last updated: Jul 05 2025 at 12:14 UTC