mirrexagon / nixpkgs-esp-dev

Nix flake and overlay for ESP8266 and ESP32 development.
Creative Commons Zero v1.0 Universal
143 stars 71 forks source link

`idf.py set-target esp32s3` is failing on MacOS, the gcc wrapper in the store seems to be misnamed. #67

Closed aidancully closed 1 month ago

aidancully commented 1 month ago
aidan@Aidans-MBP nixpkgs-esp-dev % nix --experimental-features 'nix-command flakes' develop github:mirrexagon/nixpkgs-esp-dev#esp32s3-idf
Aidans-MBP:mk4.2 aidan$ idf.py set-target esp32s3
WARNING: Python interpreter "/nix/store/0x90lz1b64a99q3jqwn0y2dia78cn2i9-python3-3.12.4-env/bin/python3.12" used to start idf.py is not from installed venv "/nix/store/m0w57jfwnj98zajn8g36kp0d6w2xzrhw-esp-idf-v5.3/python-env"
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options.
Executing action: fullclean
Build directory '/Volumes/devel/TARGET/build' not found. Nothing to clean.
Executing action: set-target
Set Target to: esp32s3, new sdkconfig will be created.
Running cmake in directory /Volumes/devel/TARGET/build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DPYTHON=/nix/store/0x90lz1b64a99q3jqwn0y2dia78cn2i9-python3-3.12.4-env/bin/python3.12 -DESP_PLATFORM=1 -DIDF_TARGET=esp32s3 -DCCACHE_ENABLE=0 /Volumes/devel/TARGET"...
-- Found Git: /nix/store/0hiwlijxhs9mvigjfsggl5rkr4gpk52q-git-2.45.2/bin/git (found version "2.45.2")
-- git rev-parse returned 'fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).'
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- The ASM compiler identification is unknown
-- Found assembler: /nix/store/1325h8qv4z8dmya6m3wj6arvlb0v8qyf-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /nix/store/1325h8qv4z8dmya6m3wj6arvlb0v8qyf-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc
-- Check for working C compiler: /nix/store/1325h8qv4z8dmya6m3wj6arvlb0v8qyf-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc - broken
CMake Error at /nix/store/rv1sx6lj8x5ffik7vzy0m3w0a4ci6pnx-cmake-3.29.6/share/cmake-3.29/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/nix/store/1325h8qv4z8dmya6m3wj6arvlb0v8qyf-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/Volumes/devel/TARGET/build/CMakeFiles/CMakeScratch/TryCompile-bqJ2t0'

    Run Build Command(s): /nix/store/9qspc35aaq7akv58lchwsxvliy1vvxl5-ninja-1.12.1/bin/ninja -v cmTC_4ba04
    [1/2] /nix/store/1325h8qv4z8dmya6m3wj6arvlb0v8qyf-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc   -mlongcalls  -fno-builtin-memcpy -fno-builtin-memset -fno-builtin-bzero -fno-builtin-stpcpy -fno-builtin-strncpy -o CMakeFiles/cmTC_4ba04.dir/testCCompiler.c.obj -c /Volumes/devel/TARGET/build/CMakeFiles/CMakeScratch/TryCompile-bqJ2t0/testCCompiler.c
    FAILED: CMakeFiles/cmTC_4ba04.dir/testCCompiler.c.obj 
    /nix/store/1325h8qv4z8dmya6m3wj6arvlb0v8qyf-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc   -mlongcalls  -fno-builtin-memcpy -fno-builtin-memset -fno-builtin-bzero -fno-builtin-stpcpy -fno-builtin-strncpy -o CMakeFiles/cmTC_4ba04.dir/testCCompiler.c.obj -c /Volumes/devel/TARGET/build/CMakeFiles/CMakeScratch/TryCompile-bqJ2t0/testCCompiler.c
    thread 'main' panicked at 'assertion failed: `(left == right)`
      left: `".xtensa"`,
     right: `"xtensa"`: Called tool must have pattern "xtensa-esp*-elf-*"', main.rs:123:18
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    ninja: build stopped: subcommand failed.

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  /nix/store/m0w57jfwnj98zajn8g36kp0d6w2xzrhw-esp-idf-v5.3/tools/cmake/project.cmake:564 (__project)
  CMakeLists.txt:14 (project)

-- Configuring incomplete, errors occurred!
cmake failed with exit code 1, output of the command is in the /Volumes/devel/TARGET/build/log/idf_py_stderr_output_79152 and /Volumes/devel/TARGET/build/log/idf_py_stdout_output_79152

I was able to reproduce the error by:

/nix/store/widmaiqzmp0nb8z9pvh4hb31p9v056kx-xtensa-esp-elf-esp-idf-v5.3/bin/xtensa-esp32s3-elf-gcc   -mlongcalls  -fno-builtin-memcpy -fno-builtin-memset -fno-builtin-bzero -fno-builtin-stpcpy -fno-builtin-strncpy -o foo.o -c foo.c

which resulted in:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `".xtensa"`,
 right: `"xtensa"`: Called tool must have pattern "xtensa-esp*-elf-*"', main.rs:123:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I notice that that version of gcc is a shell-script:

bash-3.2# cat xtensa-esp32s3-elf-gcc
#! /nix/store/iafzjk7zbkqaszqfp6n006vvxjrpn4f6-bash-5.2p32/bin/bash -e
exec -a "$0" "/nix/store/widmaiqzmp0nb8z9pvh4hb31p9v056kx-xtensa-esp-elf-esp-idf-v5.3/bin/.xtensa-esp32s3-elf-gcc-wrapped"  "$@" 

If I change .xtensa-esp32s3-elf-gcc-wrapped to xtensa-esp32s3-elf-gcc-wrapped, and also edit the store to mv .xtensa-esp32s3-elf-gcc-wrapped xtensa-esp32s3-elf-gcc-wrapped, compilation succeeds, but this obviously isn't a real solution to my problem. I'm not sure what's going on, yet.

aidancully commented 1 month ago

Getting rid of wrapProgram allowed my build to succeed. I'm new to nix, I'm sure there's a better way to do this.

index 349bff6..d837977 100644
--- a/pkgs/esp-idf/tools.nix
+++ b/pkgs/esp-idf/tools.nix
@@ -96,7 +96,7 @@ let
           makeWrapper ${fhsEnv}/bin/${pname}-env $FILE_PATH --add-flags $WRAPPED_FILE_PATH ${lib.strings.concatStringsSep " " exportVarsWrapperArgsList}
         ''
       else
-      ''wrapProgram $FILE_PATH ${lib.strings.concatStringsSep " " exportVarsWrapperArgsList}'';
+      ''echo hello'';
       in ''
         cp -r . $out
aidancully commented 1 month ago

The error appears to come from espressif's tool wrappers. This uses std::env::current_exe() to get the name of the executable, which does not appear to honor the argv[0] override (exec -a "$0") generated by wrapProgram. I tested this by creating a simple Rust app:

fn main() {
    println!("{:?}", std::env::current_exe());
}

and, when compiling and running that via % sh -c 'exec -a hello ./target/debug/foo', I see:

Ok("/Users/aidan/devel/test/foo/target/debug/foo")

It seems that wrapProgram won't work for tools that espressif already wraps in this way.

mirrexagon commented 1 month ago

Hopefully #68 fixes this!