Unable to create a working environment. about esp-idf-sys

[MabezDev]

What version of esp-idf-sys are you using? I believe there was an issue in an older release building libsodium.

[Jezza]

Just the one that rust-esp32-std-demo uses: 0.21.1

https://github.com/ivmarkov/rust-esp32-std-demo/blob/main/Cargo.toml#L58:

esp-idf-sys = { version = "0.21.1", features = ["binstart"] }

There does seem to be a newer one out.
I'll switch to that, and see if that works.
If so, I'll make a PR for it.

[MabezDev]

If you are on windows, this could also be a long file path issue. Maybe try out the native feature of esp-idf-sys if the new version one.

[Jezza]

It seems that esp-idf-svc and friends are all on 0.21.
I'll try out the native feature, and see how that goes.

And failing that, I'll patch the libraries, and bump the version for all of them.

[Jezza]

Seems I can't build esp-idf-sys with the native, as it fails with unable to find Ninja.
Patching it, and telling it to find ninja, just results in some weird output.

native feature:

patched version: (So it's looking for ninja)

[Jezza]

I'll go install ninja, and see if it works with that.

[Jezza]

Ninja is installed, and working.
Seems that it's looking for xtensa-esp32-elf-gcc.

[N3xed]

This really shouldn't happen, cmake is somehow not getting the correct PATH set (both gcc and ninja are automatically installed by the build script).

You could try printing the PATH variable inside the CMakeLists.txt file, by adding the line message(STATUS "$ENV{PATH}") to the beginning of it. Add the line to the CMakeLists.txt inside the out dir of esp-idf-sys and try recompiling with cargo build -vv.

One issue that could cause this is if you have cygpath in your PATH. Try running cygpath if it works and your not inside git-bash or the likes, this would probably cause issues. Also try compiling your project with git-bash itself.

[Jezza]

Ok, after some troubleshooting, it's definitely because I have cygpath on my PATH.

The problematic code is in embuild.
By the looks of it, cygwin (or more specifically, git-bash), does set some env variables that could be looked at, just to make sure the tty is, in fact, from cygwin.

However, that's not all.
That, unfortunately, leads me straight into another issue.
Whether I patch embuild or if I run it directly from mingw64, the issue is the same:

I'm going to assume the -I args are wrong, so I'll start looking through them.

[Jezza]

Weird.
Maybe a symlink was supposed to be generated.

I've found the files, but the includes are pointing to a completely different location.

[N3xed]

I think you're running into windows path length limitations: see Microsoft docs.

[N3xed]

Ok, after some troubleshooting, it's definitely because I have cygpath on my PATH.

The problematic code is in embuild. By the looks of it, cygwin (or more specifically, git-bash), does set some env variables that could be looked at, just to make sure the tty is, in fact, from cygwin.

I've created a new release that should fix this issue. I guess the first workaround that I implemented to circumvent issues with msys or cygwin on Windows was not that great, but these problems should be fixed now.

[Jezza]

Weird, even after setting the long paths flag, I'm still getting the same error.

I played around with it a bit and got a new error:

I'm a bit lost with this one though...

[N3xed]

I played around with it a bit and got a new error:

I'm a bit lost with this one though...

This error is unrelated, I'm not sure how it happens but I fixed it by just copying the other binaries (like cargo,
cargo-clippy, cargo-fmt, clippy-driver and rustfmt) from the nightly toolchain to the esp toolchain. I think it has to do with cargo concurrently linking to these executables (the nightly ones are used if the used toolchain doesn't have them).

Note: You have to copy the .dlls too (.pdbs should only be needed for debugging purposes, but why not copy them too).

We should really open an issue for this one upstream, and for the temporary fix in rust-build (maybe).

[georgik]

@Jezza The first error is caused by too long build path. Move the project to shorter path. This is known limitation of Windows build via Platform IO. It's quite misleading that it fails on libsodium. The libsodium is the first library which has files on very long paths, so the build fails there.

[Jezza]

@georgik I'm not building it with Platform IO anymore, I switched to native.
I also ended up enabling long paths in windows.

The current issue I'm facing is still being unable to find headers:

[georgik]

Just FYI @Jezza Long Paths on Windows does not solve the problem. For some unknown reason this setting is ignored during the build.

[Jezza]

Ah, I see.
Nice to know.

[N3xed]

With a little bit of research this seems to be a gcc limitation.

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.

If this is a common issue, it may be worth trying to implement a workaround (for example forcing cmake to use relative paths, creating directory junctions ourselves, etc.).

[MabezDev]

Closing due to inactivity, I hope that by now all the issues are resolved. Please file another if this is not the case.