Unable to find RC.exe

[David-OConnor]

This is a cross-post from this https crate issue.

This crate seems sensitive to C-compiler setup; failing on Windows 10 when running cargo install https. I think it's trying to find a Visual Studio compiler that is not normally in the system path.

error: failed to run custom build command for `https v1.3.2`
process didn't exit successfully: `C:\Users\david\AppData\Local\Temp\cargo-install9Sgt9O\release\build\https-b1afe7e63ae
4afd0\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Are you sure you have RC.EXE in your $PATH?: Os { code: 2, kind: NotFound, message: "The syst
em cannot find the file specified." }', libcore\result.rs:945:5

[nabijaczleweli]

What do you get if you set RUST_BACKTRACE=full?

[David-OConnor]

Not sure how to get that command to work, but here's the rest:

    stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:65
   1: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
   2: std::sys_common::backtrace::print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:59
   3: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:211
   4: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:227
   5: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:463
   6: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:350
   7: std::panicking::rust_begin_panic
             at C:\projects\rust\src\libstd\panicking.rs:328
   8: core::panicking::panic_fmt
             at C:\projects\rust\src\libcore\panicking.rs:71
   9: core::result::unwrap_failed
  10: embed_resource::windows_msvc::compile_resource
  11: embed_resource::compile
  12: main
  13: std::rt::lang_start_internal::{{closure}}
             at C:\projects\rust\src\libstd\rt.rs:59
  14: std::panicking::try::do_call<closure,i32>
             at C:\projects\rust\src\libstd\panicking.rs:310
  15: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:105
  16: std::panicking::try
             at C:\projects\rust\src\libstd\panicking.rs:289
  17: std::panic::catch_unwind
             at C:\projects\rust\src\libstd\panic.rs:374
  18: std::rt::lang_start_internal
             at C:\projects\rust\src\libstd\rt.rs:58
  19: main
  20: invoke_main
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:64
  21: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:259
  22: BaseThreadInitThunk
  23: RtlUserThreadStart

[nabijaczleweli]

I'm guessing you're actually using the MSVC stack, then?

[David-OConnor]

I think so? I'm using Cargo, and have Visual Studio 2017 Community edition installed.

[nabijaczleweli]

Okay then, where do you have rc.exe (and does it work if you run the vcvars.bat thingy)?

[nabijaczleweli]

Turns out Jon Blow has a copy-pastable "library" that's a much more generic version of our VS acquisition code, but oh boy am I not looking forward to porting it.

[thecoshman]

Is there an ETA for this :)

[nabijaczleweli]

Funny you should ask, I just earlier today opened the aforelinked pastebin! Maybe I'll just link to it, which means I don't have to rewrite it :v

[thecoshman]

I just read the opening 'easy' on how as bad as that code is, it's actually really good despite all the pressure on it to be worse... 😢

Good luck with it! 👍

[nabijaczleweli]

@David-OConnor What do you get when you run the detect example from https://github.com/nabijaczleweli/vswhom.rs? What is the path to rc.exe on your system?

[David-OConnor]

It compiles properly when I run cargo build. I don't know what/where rc.exe is.

[nabijaczleweli]

Okay, then, what output do you get from running cargo run --example detect in that folder?

[David-OConnor]

Some(
    VsFindResult {
        windows_sdk_version: 10,
        windows_sdk_root: Some(
            "C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.17134.0"
        ),
        windows_sdk_um_library_path: Some(
            "C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.17134.0\\um\\x64"
        ),
        windows_sdk_ucrt_library_path: Some(
            "C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.17134.0\\ucrt\\x64"
        ),
        vs_exe_path: Some(
            "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\VC\\Tools\\MSVC\\14.16.27023\
\bin\\Hostx64\\x64"
        ),
        vs_library_path: Some(
            "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\VC\\Tools\\MSVC\\14.16.27023\
\lib\\x64"
        )
    }
)

[nabijaczleweli]

Posting this morning's discussion for later reference

[13:33] ((наб )женщина)(): Could someone with VS/WinSDK post their rc.exe path? [13:33] Cat Plus Plus: Don't hardcode paths to VS tools [13:34] ((наб )женщина)(): yes that's what I'm trying to avoid [13:34] ((наб *)женщина)(): but I get a path to a couple SDK/VS root dirs and I need to know the relative path to rc.exe from them to make this god-forsaken thing work :v [13:35] Cat Plus Plus: C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64 [13:37] Cat Plus Plus: If you want to automatically get VS tools on PATH the best way to do this is to run vswhere and then call vcvars64.bat [13:38] Cat Plus Plus:

for /f "usebackq delims=" %%i in (`Tools\_build\vswhere -latest -property installationPath`) do (
if exist "%%i\Common7\Tools\vsdevcmd.bat" set FoundVSPath=%%i
)

set VSCMD_START_DIR=%cd% pushd "%FoundVSPath%" call "VC\Auxiliary\Build\vcvars64.bat"

> [13:38] ((наб *)женщина)(): this is a generic build script and modifying the env sounds like big no-no
> [13:39] ((наб *)женщина)(): also lol I get `.../10.0.17134.0`, `.../10.0.17134.0/um/x64`, and `.../10.0.17134.0/ucrt/x64` from this
> [13:39] Cat Plus Plus: Then rely on the user to set the environment properly
> [13:39] ((наб *)женщина)(): yeah like that's ever gonna work lol
> [13:40] Cat Plus Plus: You'd have to dig through registry to get SDK paths otherwise
> [13:40] ((наб *)женщина)(): thnax for the path, now I can do an Educated Guess with this
> [13:40] ((наб *)женщина)(): I stole a Jon Blow™ lib
> [13:40] Cat Plus Plus: There's like 5 active SDK versions and new one coming out every 6 months :vv:
> [13:41] ((наб *)женщина)(): guess I'll just come back to the issue in 6 months
> [13:41] Cat Plus Plus: The only path you can rely on is vswhere in recent VS Installer setups
> [13:41] ((наб *)женщина)(): and probably just build vswhere internally which has gotta be Very Fun
> [13:41] Cat Plus Plus: It's at `C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe` since few VS versions ago
> [13:43] Cat Plus Plus: Also you don't have to modify the current environment, you can run vcvars64 in a new shell and then use set to print out all variables
> [13:43] ((наб *)женщина)(): sounds hellish
> [13:43] ((наб *)женщина)(): but I'll probably've to resort to it if this garbage doesn't work
> [13:43] Cat Plus Plus: Then you have WindowsSDKVersion and WindowsSdkVerBinPath
> [13:45] Cat Plus Plus: It's like `cmd /k "vcvars64.bat && set"` and then parse the output
> [13:46] ((наб *)женщина)(): oh shit nice
> [13:46] ((наб *)женщина)(): might as well slap that in there as well then :v

[nabijaczleweli]

Okay, @David-OConnor, can you clone this repository and execute cargo run -- empty-resource.rc in it?

[nabijaczleweli]

Released in v1.2.0 (doesn't mean I'm still not waiting on the tests).

[David-OConnor]

Appears to be fixed. Thanks for sorting this out!

[nabijaczleweli]

Damn, I'm old!