rustup

rustup copied to clipboard

*** Nothing to do with lock errors with ESP32 ***

Running two builds in parallel with a linked toolchain on windows:

brian@DESKTOP-CODN6ST MINGW64 /c/Users/brian/Documents/dev/rls
$ PATH="c:\Program Files\CMake\bin:$PATH" cargo +rust1-stage2 build
error: unable to unlink old fallback exe
info: caused by: Access is denied. (os error 5)

This is because of the hack where the 'fallback' cargo is copied into a temporary location for the duration of the build.

I wonder if we'd be better off dropping cargo into the linked toolchain when we link it rather than copying exes in this concurrency-unsafe fashion.

Anyhow, as a workaround, ignoring deletion errors, or perhaps retrying a couple of times, should address this.

Is there a workaround for tools like cargo-espflash which internally call cargo and then die because they're blocking themselves?

@ForsakenHarmony I suggest discussing on the cargo tracker; rustup doesn't block anything

@rbtcollins it does, in the case of cargo-espflash.

• I call cargo espflash which makes rustup copy cargo and lock it
• then cargo-espflash internally calls cargo build which fails because rustup tries to copy cargo again

@ForsakenHarmony rustup does not lock anything. Cargo has locks. Thats why I suggested discussing on the cargo bugtracker.

If you are encountering some other sort of lock, you could start by filing a specific bug about it, rather than sidetracking an existing bug that seems to be separate : I'm going to wait long enough for notification emails to be sent then mark all these comments offtopic.

Also marking that off topic @JasonKleban.

I recently commented on #2889 with a possible solution to this issue.