Yet another thread 'main' panicked Rust gotcha -- mind your build.rs

Picking up the little Rust project I'd set aside in late summer, with the latest release, I got

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "The system
 cannot find the file specified." } }', ../src/libcore\result.rs:837

Setting environment variable RUST_BACKTRACE to 1, and retrying gave

stack backtrace:
   0:   0xf314b7 - std::panicking::default_hook
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libstd\panicking.rs:263
   1:   0xf31caa - std::panicking::rust_panic_with_hook
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libstd\panicking.rs:451
   2:   0xf31b47 - std::panicking::begin_panic<collections::string::String>
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libstd\panicking.rs:413
   3:   0xf31a86 - std::panicking::begin_panic_fmt
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libstd\panicking.rs:397
   4:   0xf319e2 - std::panicking::rust_begin_panic
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libstd\panicking.rs:373
   5:   0xf36f82 - core::panicking::panic_fmt
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libcore\panicking.rs:69
   6:   0xf22402 - core::result::unwrap_failed<std::io::error::Error>
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libcore\macros.rs:29
   7:   0xf21d0f - core::result::Result<std::process::ExitStatus, std::io::error::Error>::unwrap<std::process::ExitStatu
s,std::io::error::Error>
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libcore\result.rs:737
   8:   0xf23b5e - build_script_build::main
                at c:\Users\steve\hg\Projects\rust\HelloWorld\build.rs:8
   9:   0xf3556b - panic_unwind::__rust_maybe_catch_panic
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libpanic_unwind\lib.rs:97
  10:   0xf322f0 - std::rt::lang_start
                at C:\bot\slave\stable-dist-rustc-win-msvc-32\build\src\libstd\rt.rs:51
  11:   0xf23d01 - main
  12:   0xf39768 - __scrt_common_main_seh
                at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  13: 0x75168e93 - BaseThreadInitThunk
  14: 0x772d9bc2 - RtlDestroyQueryDebugBuffer

which wasn't particularly helpful.

Resolution was an inspired guess -- my build.rs contained a path which ran a command by explicit path into the windows SDK for an x64 machine, when I was trying on an old 32-bit box.

Fixing the path to be selected according to whether the file actually exists resolved the issue.

Another little MSVC Rust gotcha.

I've now set up VSCode with Rust on three machines -- the first two went without a hitch; the latest simply refused when running cargo install racer to compile kernel32-sys, with a x86/x64 mismatch.

And running dumpbin /headers on the system libraries mentioned in the dump of the failing link command, sure enough the x86 versions were being picked up by default. Now, going in and doing environment surgery started to unblock the system, but I wanted to figure out why this machine was giving problems.

Much scratching of head later, I realised that the first machine I'd run the command in a PowerShell window without running the Visual Studio VSVARS32.BAT, and that on the second, though I had run that environment set-up as part of my PowerShell profile, that one was running WinX/x86.

Moral of the story -- don't run cargo install from a Visual Studio prompt.

Rain brings on the Rust

One thing that the wet weather in recent weeks accomplished was to give me some time to play with Rust again, after a go-round a couple of years back, when it still needed to run in an mingw prompt, the code was full of sigils, and I couldn't get an executable to link against advapi32.dll; then again towards the end of 2014 when I migrated a fork of the rust-windows project to the then-current version.

Last year was a bit of a wash all over, coding for fun being one of the major casualties of the year, so it was pretty much a start anew, to build myself a simple "hello world", porting a simple Win32 program to the new language.

It was reasonably easy to find useful samples and fragments from which to Frankenstein together a working program. What I did not find, however, was any good guide to adding resources to the project using the native (rather than the foreign) tool-chain. So I cast around a bit and hacked this together:

It's hacky, since it builds the .rc file to a .res file that actually calls itself a .lib, so that the cargo tool will add the extensionless name as a .lib to the linker, and the linker, fortunately, ignores the file extension and just looks at the file content. It's also hacky in that it hard-codes the path to a local rc.exe, and works around the fact that that tool does not offer an output directory parameter by tree-walking from the directory where we want to place the output to where the source resides.

I'm sure there must be a better way, but this works. Apart from the fact that a VERSIONINFO compiles OK into the resulting .exe (as can be seen by opening it in Visual Studio), but doesn't show in the file properties. Application icons work just fine, though.

Rain causes Rust

One thing that the wet weather in recent weeks accomplished was to give me some time to play with Rust again, after a go-round a couple of years back, when it still needed to run in an mingw prompt, the code was full of sigils, and I couldn't get an executable to link against advapi32.dll; then again towards the end of 2014 when I migrated a fork of the rust-windows project to the then-current version.

Last year was a bit of a wash all over, coding for fun being one of the major casualties of the year, so it was pretty much a start anew, to build myself a simple "hello world", porting a simple Win32 program to the new language.

It was reasonably easy to find useful samples and fragments from which to Frankenstein together a working program. What I did not find, however, was any good guide to adding resources to the project using the native (rather than the foreign) tool-chain. So I cast around a bit and hacked this together:

It's hacky, since it builds the .rc file to a .res file that actually calls itself a .lib, so that the cargo tool will add the extensionless name as a .lib to the linker, and the linker, fortunately, ignores the file extension and just looks at the file content. It's also hacky in that it hardcodes the path to a local rc.exe, and works arounf the fact that that tool does not offer an output directory parameter by treewalking from the directory where we want to place the output to where the source resides.

I'm sure there must be a better way, but this works. Apart from the fact that a VERSIONINFO compiles OK into the resulting .exe (as can be seen by opening it in Visual Studio), but doesn't show in the file properties. Application icons work just fine, though.