Error: Too long output directory #252

achieve-dream1221 · 2023-10-19T02:00:58Z

create a project by cargo generate esp-rs/esp-idf-template cargo
and then, run cargo build

error: failed to run custom build command for `esp-idf-sys v0.33.3`

Caused by:
process didn't exit successfully: E:\rust\esp32-std-project\target\debug\build\esp-idf-sys-7beb8c60ac8a9a8b\build-script-build (exit code: 1)
--- stderr
Error: Too long output directory: \\?\E:\rust\esp32-std-project\target\xtensa-esp32-espidf\debug\build\esp-idf-sys-168dae4d88221cf9\out. Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!
warning: build failed, waiting for other jobs to finish...

Tasks

Give feedback

No tasks being tracked yet.

Options

The text was updated successfully, but these errors were encountered:

0x1f57 · 2023-10-19T07:55:13Z

this works for me

in project

you may also need to "cargo clean" and delete the ".embuild" folder

Vollbrecht · 2023-10-19T13:47:18Z

On windows please try to put your projects in root project like C:\your-project to make the path as short as possible or use WSL as it has not such a problem. This is a windows specific problem we cant influence.

emeric-martineau · 2023-10-19T15:31:15Z

In my case, ESP_IDF_PATH_ISSUES works but I have another error after:

Caused by:
  process didn't exit successfully: `D:\rust\esp32-std-blink-led\target\debug\build\esp-idf-sys-7beb8c60ac8a9a8b\build-script-build` (exit code: 1)
  --- stdout
  cargo:warning=(esp-idf-sys) Too long output directory: `\\?\D:\rust\esp32-std-blink-led\target\xtensa-esp32-espidf\debug\build\esp-idf-sys-168dae4d88221cf9\out`. Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows `subst` do NOT work!
  cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
  cargo:rerun-if-env-changed=MCU
  cargo:rerun-if-env-changed=ESP_IDF_SYS_ROOT_CRATE
  cargo:rerun-if-env-changed=ESP_IDF_VERSION
  cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
  cargo:rerun-if-env-changed=ESP_IDF_CMAKE_GENERATOR
  cargo:rerun-if-env-changed=IDF_PATH
  cargo:rerun-if-env-changed=EXTRA-COMPONENTS
  cargo:rerun-if-env-changed=ESP_IDF_COMPONENTS
  cargo:rerun-if-env-changed=ESP_IDF_COMPONENT_MANAGER
  Submodule path 'components/asio/asio': checked out 'f31694c9f1746ba189a4bcae2e34db15135ddb22'
  Submodule path 'components/bootloader/subproject/components/micro-ecc/micro-ecc': checked out 'd037ec89546fad14b5c4d5456c2e23a71e554966'
  Submodule path 'components/bt/controller/lib_esp32': checked out '7bb0d445db3414ce96d21c50ba9249125d41480f'
  Submodule path 'components/bt/controller/lib_esp32c3_family': checked out '0cfac1b21ebc995e8e9aa040ab1ab29deee4f580'
  Submodule path 'components/bt/host/nimble/nimble': checked out 'e2d7a766fb3927d008902611b3985e8595864c55'
  Submodule path 'components/cbor/tinycbor': checked out '7c349dbb6b8d76db39383b226d3ebdf59b8ab37d'
  Submodule path 'components/cmock/CMock': checked out 'eeecc49ce8af123cf8ad40efdb9673e37b56230f'
  Submodule path 'components/cmock/CMock/vendor/c_exception': checked out '71b47be7c950f1bf5f7e5303779fa99a16224bb6'
  Submodule path 'components/cmock/CMock/vendor/unity': checked out 'cf949f45ca6d172a177b00da21310607b97bc7a7'
  Submodule path 'components/coap/libcoap': checked out '3aa11612c143c9734d72022720f33e12506f7a2c'
  Submodule path 'components/coap/libcoap/ext/tinydtls': checked out '59055b8a935bc53bf69d002fc089ad4bd08851b2'
  Submodule path 'components/esp_phy/lib': checked out '32583f98f229ab9b3c48aa3a10f954fcdddfe4d1'
  Submodule path 'components/esp_wifi/lib': checked out 'a9f72f895dd74bb763f1ff9146203ff57846ab5d'
  Submodule path 'components/esptool_py/esptool': checked out '7b17ea072fbac0f92fc417ddbe34e28afbd8ced0'
  Submodule path 'components/expat/expat': checked out '454c6105bc2d0ea2521b8f8f7a5161c2abd8c386'
  Submodule path 'components/ieee802154/lib': checked out 'f7b5e8059a3bb6f321e79ac3bf2aa4d2a9b93326'
  Submodule path 'components/json/cJSON': checked out 'd348621ca93571343a56862df7de4ff3bc9b5667'
  Submodule path 'components/libsodium/libsodium': checked out '4f5e89fa84ce1d178a6765b8b46f2b6f91216677'
  Submodule path 'components/lwip/lwip': checked out '4f24c9baf9101634b7c690802f424b197b3bb685'
  Submodule path 'components/mbedtls/mbedtls': checked out '1d7033af30e20ccb2a0c0a114d3a08e372430f34'
  Submodule path 'components/mqtt/esp-mqtt': checked out 'bb9c8af9d552b608dd3aabf9617bde757a538ebe'
  Submodule path 'components/nghttp/nghttp2': checked out '8f7b008b158e12de0e58247afd170f127dbb6456'
  Submodule path 'components/nghttp/nghttp2/third-party/mruby': checked out '7c91efc1ffda769a5f1a872c646c82b00698f1b8'
  Submodule path 'components/nghttp/nghttp2/third-party/neverbleed': checked out 'b967ca054f48a36f82d8fcdd32e54ec5144f2751'
  Submodule path 'components/openthread/lib': checked out '9a8d34d8f698cad2c9468468b473e26a3dda51b9'
  Submodule path 'components/openthread/openthread': checked out 'c36c0e77a2465355bcf13bd7dc718d8c9aa6ff64'
  Submodule path 'components/protobuf-c/protobuf-c': checked out 'abc67a11c6db271bedbb9f58be85d6f4e2ea8389'
  Submodule path 'components/spiffs/spiffs': checked out '0dbb3f71c5f6fae3747a9d935372773762baf852'
  Submodule path 'components/tinyusb/tinyusb': checked out 'c4badd394eda18199c0196ed0be1e2d635f0a5f6'
  Submodule path 'components/unity/unity': checked out '7d2bf62b7e6afaf38153041a9d53c21aeeca9a25'
  Submodule path 'examples/build_system/cmake/import_lib/main/lib/tinyxml2': checked out '7e8e249990ec491ec15990cf95b6d871a66cf64a'
  Submodule path 'examples/peripherals/secure_element/atecc608_ecdsa/components/esp-cryptoauthlib': checked out '36d0642e66ff5b1c7a291873f24c498ca6ffedef'

To use WSL2, remember, that WSL2 don't have access to your USB device.
You must install Rust both under Linux and Windows.

Under linux, install all ESP32 tools (see https://esp-rs.github.io/book/).
Under Windows install only espflash and run:

# To upload binary
$ espflash.exe flash --port COM3 esp32-std-blink-led
# To upload and display log from you code
$ espflash.exe flash --port COM3 --monitor esp32-std-blink-led

Where esp32-std-blink-led is you ELF binary after compile found in your Rust project target/xtensa-esp32-espidf/debug/

It works for me.

achieve-dream1221 · 2023-10-20T07:51:55Z

this works for me

in project

you may also need to "cargo clean" and delete the ".embuild" folder

thank you so much, it worked!

Julien-cpsn · 2023-10-20T21:32:57Z

this works for me

in project

you may also need to "cargo clean" and delete the ".embuild" folder

Just for precision : this line goes into the .cargo/config.toml file

xobs · 2023-10-24T02:06:49Z

I think this workaround should be enabled by default if it isn't fatal. Note that the recommended workaround doesn't work, so the documentation should be updated to reflect this approach instead: https://esp-rs.github.io/book/misc/troubleshooting.html#long-path-names

ivmarkov · 2023-10-28T11:51:17Z

I think this workaround should be enabled by default if it isn't fatal. Note that the recommended workaround doesn't work, so the documentation should be updated to reflect this approach instead: https://esp-rs.github.io/book/misc/troubleshooting.html#long-path-names

What workaround should be enabled by default if it isn't fatal? If you mean ESP_IDF_PATH_ISSUES=warn - this is BAD, because - depending on what bits and pieces you use from ESP IDF - your build might fail in weird ways (partial git clones, strange build errors). This workaround is a bit "use at your own risk".

And I'm not enabling it by default no matter what, as we were flooded by "I have a weird build failure on Windows" errors before.

As for the trick described in the ESP book, I don't know why it is there, given that - last time I checked - it does NOT work for esp-idf-sys. Again, the error message is:
{quote}
Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!
{quote}

(Emphasis mine.)

Otherwise, thanks to you and the rest of the folks trying to help! Unfortunately I'm not very optimistic we can improve the "too long Windows path" issue handling beyond what we have and what we suggest.

ivmarkov · 2023-10-28T11:51:52Z

UPDATE: For the "subst" trick - I've posted a question in the Matrix chat as I'm not sure who was ever successfully using that. But other than that, not sure what else to do here. Closing :)

Tastaturtaste · 2023-12-05T20:39:41Z

UPDATE: For the "subst" trick - I've posted a question in the Matrix chat as I'm not sure who was ever successfully using that. But other than that, not sure what else to do here. Closing :)

I just successfully used that trick. What error did you @ivmarkov get when trying it out? Did you have windows long path support set up correctly?

ivmarkov · 2024-01-03T14:04:27Z

@Tastaturtaste

UPDATE: For the "subst" trick - I've posted a question in the Matrix chat as I'm not sure who was ever successfully using that. But other than that, not sure what else to do here. Closing :)

I just successfully used that trick. What error did you @ivmarkov get when trying it out? Did you have windows long path support set up correctly?

This trick (SUBST) does not work, plain and simple. I have in the meantime tested it.
The link you've pasted w.r.t. regedits mentions that there are TWO issues that need to be fulfilled for that to work. The regedit is just one of them.

archifo · 2024-02-03T16:54:37Z

Does it mean that it is definitively impossible to use Rust for espressif on windows ? Sorry but I'm quite angry.
Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?
I've never seen this kind of problem with other chipsets supporting Rust...

ivmarkov · 2024-02-03T18:12:20Z

Does it mean that it is definitively impossible to use Rust for espressif on windows ?

It is possible.
In the original bug report, as well as throughout the thread that follows, as well as in the error message that the build spits out, the solution is given:

"Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!"

Sorry but I'm quite angry.

Espressif is currently investing (as in hired, full time developers) in the baremetal crates, not the ones which are based on top of ESP-IDF. Either because they consider the baremetal solutions more important, or because they think the ESP-IDF crates are in the meantime relatively mature, or both. Speculating here a bit, but that's the status quo.

Therefore, the effort put into esp-idf-sys/hal/svc is based on mine (and others) free time. As in good will and so on.

Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?

Not sure for that suggestion. Might or might not work. If we go this route, we have to put not just build artefacts, but also the ESP IDF git repo itself in something like /tmp/<short-tmp-dir>.

Another solution would be to make sure that ALL tools involved in building the esp-idf-sys crate itself as well as the ESP-IDF itself understand long paths, and if not - fix them. Perhaps possible, but definitely not easy.

You also need to realize, that the "please use a short project path" restriction is coming from ESP IDF itself. It is just that the cargo build system is making it worse (as in the project path needs to be even shorter).

I've never seen this kind of problem with other chipsets supporting Rust...

Espressif's ESP IDF is unique in its class in that it provides you a Rust STD environment. On an MCU. Therefore, I think this "short project path" constraint on pure Windows (it does not exist with WSL2's native file system) is a small price to pay for that. Surely annoying, but tolerable. But then - IMO. Perhaps if you or other folks find this really inconvenient, you can work towards a solution?

N3xed · 2024-02-03T18:16:49Z

Does it mean that it is definitively impossible to use Rust for espressif on windows ? Sorry but I'm quite angry. Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea? I've never seen this kind of problem with other chipsets supporting Rust...

Well, you can always give your hands on trying to create a workaround for this. I originally wrote this compilation infrastructure on Windows, where we ran into command-line length limitations (see #7 (comment) and espressif/esp-idf#7864), which was fixed by using response files and preventing the linker to expand the response files while running the jobs.

Then, someone ran into Windows file path limitations (see #23). Which seems to be caused by gcc no supporting long paths on Windows (see my comment #23 (comment)). There may be other tools that we're using that also don't support this (e.g. I seem to remember there were some issues with git and too long paths as well).

The original workarounds I posted are:

Possible workarounds:

Use subst to assign a virtual drive letter to a path (should work as pointed out here).

Create a directory junction (with mklink /j) to shorten the path (not tested).

Moving the project to a directory with a shorter path.

Where point one seems not to work. But maybe point 2 could? The issue is also with the system headers (e.g. for newlib) which reside in the .embuild directory. So I think only moving your project to a shorter path may not actually help if your .embuild folder where the toolchain is stored is also at a long path. But almost certainly the root cause is still GCC not supporting long paths.

I've been pretty inactive, and am also not building stuff with esp-idf-sys, so I've not looked into workarounds further. But again if anyone wants improvements in this regard, you'd (or anyone) have to it yourself.

Tastaturtaste · 2024-02-03T18:38:29Z

Regarding the gcc side of the problem there is this tracked bug. According to one of the comments the fix was simply to add a manifest to enable long path support on windows. It seems nobody has pursued this further.

RingCanary · 2024-08-30T06:30:47Z

Does it mean that it is definitively impossible to use Rust for espressif on windows ?

It is possible. In the original bug report, as well as throughout the thread that follows, as well as in the error message that the build spits out, the solution is given:

"Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!"

Sorry but I'm quite angry.

Espressif is currently investing (as in hired, full time developers) in the baremetal crates, not the ones which are based on top of ESP-IDF. Either because they consider the baremetal solutions more important, or because they think the ESP-IDF crates are in the meantime relatively mature, or both. Speculating here a bit, but that's the status quo.

Therefore, the effort put into esp-idf-sys/hal/svc is based on mine (and others) free time. As in good will and so on.

Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?

Not sure for that suggestion. Might or might not work. If we go this route, we have to put not just build artefacts, but also the ESP IDF git repo itself in something like /tmp/<short-tmp-dir>.

Another solution would be to make sure that ALL tools involved in building the esp-idf-sys crate itself as well as the ESP-IDF itself understand long paths, and if not - fix them. Perhaps possible, but definitely not easy.

You also need to realize, that the "please use a short project path" restriction is coming from ESP IDF itself. It is just that the cargo build system is making it worse (as in the project path needs to be even shorter).

I've never seen this kind of problem with other chipsets supporting Rust...

Espressif's ESP IDF is unique in its class in that it provides you a Rust STD environment. On an MCU. Therefore, I think this "short project path" constraint on pure Windows (it does not exist with WSL2's native file system) is a small price to pay for that. Surely annoying, but tolerable. But then - IMO. Perhaps if you or other folks find this really inconvenient, you can work towards a solution?

It's better to use WSL2 as recommended and please refer this to bind the usb ports to the hosted linux distro -- things works like a charm :)

ivmarkov · 2024-08-30T10:02:37Z

Does it mean that it is definitively impossible to use Rust for espressif on windows ?

It is possible. In the original bug report, as well as throughout the thread that follows, as well as in the error message that the build spits out, the solution is given:
"Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!"

Sorry but I'm quite angry.

Espressif is currently investing (as in hired, full time developers) in the baremetal crates, not the ones which are based on top of ESP-IDF. Either because they consider the baremetal solutions more important, or because they think the ESP-IDF crates are in the meantime relatively mature, or both. Speculating here a bit, but that's the status quo.
Therefore, the effort put into esp-idf-sys/hal/svc is based on mine (and others) free time. As in good will and so on.

Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?

Not sure for that suggestion. Might or might not work. If we go this route, we have to put not just build artefacts, but also the ESP IDF git repo itself in something like /tmp/<short-tmp-dir>.
Another solution would be to make sure that ALL tools involved in building the esp-idf-sys crate itself as well as the ESP-IDF itself understand long paths, and if not - fix them. Perhaps possible, but definitely not easy.
You also need to realize, that the "please use a short project path" restriction is coming from ESP IDF itself. It is just that the cargo build system is making it worse (as in the project path needs to be even shorter).

I've never seen this kind of problem with other chipsets supporting Rust...

Espressif's ESP IDF is unique in its class in that it provides you a Rust STD environment. On an MCU. Therefore, I think this "short project path" constraint on pure Windows (it does not exist with WSL2's native file system) is a small price to pay for that. Surely annoying, but tolerable. But then - IMO. Perhaps if you or other folks find this really inconvenient, you can work towards a solution?

It's better to use WSL2 as recommended and please refer this to bind the usb ports to the hosted linux distro -- things works like a charm :)

You are preaching to the wrong choir. I never said it does not work or that WSL2 is not a good workaround. If you would like to help, a paragraph to the README of esp-idf-template dedicated to Windows+WSL2, including some instructions what to install so that espflash works from inside WSL2 would be really, really appreciated.

RingCanary · 2024-08-31T10:48:21Z

Happy to help, will definitely do so over this weekend @ivmarkov.

jessebraham added this to esp-rs Oct 19, 2023

github-project-automation bot moved this to Todo in esp-rs Oct 19, 2023

ivmarkov closed this as completed Oct 28, 2023

github-project-automation bot moved this from Todo to Done in esp-rs Oct 28, 2023

ivmarkov mentioned this issue Oct 28, 2023

subst is not a solution for the long path names on Windows esp-rs/book#125

Merged

lz1998 mentioned this issue Dec 16, 2023

避免Too long output directory错误 lz1998/evil-apple-juice-esp32-rs#4

Merged

David-OConnor mentioned this issue Jan 2, 2024

Windows Bug: Shorten your project path down to no more than 10 characters #266

Open

cortices mentioned this issue May 13, 2024

Spaces in path causes esp32-s2 build to fail with error referencing bootloader.elf (IDFGH-3641) espressif/esp-idf#5576

Closed

RingCanary mentioned this issue Sep 1, 2024

Add WSL2 Setup Guide README esp-rs/esp-idf-template#232

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error: Too long output directory #252

Error: Too long output directory #252

achieve-dream1221 commented Oct 19, 2023 •

edited

Loading

Tasks

0x1f57 commented Oct 19, 2023 •

edited

Loading

Vollbrecht commented Oct 19, 2023

emeric-martineau commented Oct 19, 2023 •

edited

Loading

achieve-dream1221 commented Oct 20, 2023

Julien-cpsn commented Oct 20, 2023

xobs commented Oct 24, 2023

ivmarkov commented Oct 28, 2023

ivmarkov commented Oct 28, 2023

Tastaturtaste commented Dec 5, 2023

ivmarkov commented Jan 3, 2024

archifo commented Feb 3, 2024

ivmarkov commented Feb 3, 2024 •

edited

Loading

N3xed commented Feb 3, 2024

Tastaturtaste commented Feb 3, 2024

RingCanary commented Aug 30, 2024

ivmarkov commented Aug 30, 2024

RingCanary commented Aug 31, 2024

Error: Too long output directory #252

Error: Too long output directory #252

Comments

achieve-dream1221 commented Oct 19, 2023 • edited Loading

error: failed to run custom build command for esp-idf-sys v0.33.3

Tasks

0x1f57 commented Oct 19, 2023 • edited Loading

Vollbrecht commented Oct 19, 2023

emeric-martineau commented Oct 19, 2023 • edited Loading

achieve-dream1221 commented Oct 20, 2023

Julien-cpsn commented Oct 20, 2023

xobs commented Oct 24, 2023

ivmarkov commented Oct 28, 2023

ivmarkov commented Oct 28, 2023

Tastaturtaste commented Dec 5, 2023

ivmarkov commented Jan 3, 2024

archifo commented Feb 3, 2024

ivmarkov commented Feb 3, 2024 • edited Loading

N3xed commented Feb 3, 2024

Tastaturtaste commented Feb 3, 2024

RingCanary commented Aug 30, 2024

ivmarkov commented Aug 30, 2024

RingCanary commented Aug 31, 2024

achieve-dream1221 commented Oct 19, 2023 •

edited

Loading

error: failed to run custom build command for `esp-idf-sys v0.33.3`

0x1f57 commented Oct 19, 2023 •

edited

Loading

emeric-martineau commented Oct 19, 2023 •

edited

Loading

ivmarkov commented Feb 3, 2024 •

edited

Loading