[BUG] Unable to build on HomeAssistant OS

[popjelev]

When I try to build I get an error. Please note I've cleared build files, removed all previous files and so on. ESPHome is in a container in HomeAssistant OS and I cannot access it. Please advice. I have this issue for as long as I can remember but I have working build on the device, just can't upgrade it :(

To Reproduce Steps to reproduce the behavior:

1. Go to ESPEasy Dashboard
2. Click tripple-dot menu
3. Click on Install
4. Click on Wirelessly
5. Wait build to finish with an error

Expected behavior Should be build properly

Additional context

Contents of bedside-lamp-small-bedroom.yaml

substitutions:
  name: bedside-lamp-small-bedroom
  friendly_name: Bedside Lamp (small bedroom)

packages:
  bslamp2:
    url: https://github.com/mmakaay/esphome-xiaomi_bslamp2
    ref: release/2021.10.0
    files:
      - packages/core.yaml
      - packages/behavior_default.yaml
      - packages/ota_feedback.yaml
      - packages/activate_preset_svc.yaml
    refresh: 0s

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  use_address: "XX.XX.XX.XX"

api:
  password: !secret api_password

ota:
  password: !secret ota_password

Output of the builder

INFO Reading configuration /config/esphome/bedside-lamp-small-bedroom.yaml...
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@release/2021.10.0
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@release/2021.10.0
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing bedside-lamp-small-bedroom (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40302.0 (4.3.2) 
 - tool-cmake @ 3.16.9 
 - tool-ninja @ 1.10.2 
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch2 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch2 
 - toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2
Reading CMake configuration...
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- The ASM compiler identification is unknown
-- Found assembler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -- broken
-- Configuring incomplete, errors occurred!
See also "/data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/CMakeFiles/CMakeOutput.log".
See also "/data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/CMakeFiles/CMakeError.log".

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/tool-cmake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/CMakeFiles/CMakeTmp

    Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_b0c4f && [1/2] Building C object CMakeFiles/cmTC_b0c4f.dir/testCCompiler.c.obj
    FAILED: CMakeFiles/cmTC_b0c4f.dir/testCCompiler.c.obj 
    /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc   -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_b0c4f.dir/testCCompiler.c.obj   -c testCCompiler.c
    /bin/sh: 1: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc: not found
    ninja: build stopped: subcommand failed.

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:311 (__project)
  CMakeLists.txt:3 (project)

========================= [FAILED] Took 10.47 seconds =========================

[mmakaay]

I have seen the issue before, but I've never been able to find a fix for this. The problem lies not within my repository code (unfortunately, otherwise I could try to fix it), but in the build chain which seems to be broken.

Of course I am interested to see if there's anything I can do to fix this. As a matter of fact, I have been waiting for quite a while now to get hold of a new raspberry pi that I can use to install Home Assistant OS on to emulate issues like this one. But the chip shortage is very much bugging this process :-(

Another route would be to compile the firmware on a different system than the Home Assistant addon environment. It really doesn't mind whether or not the addon is used. It is basically a compilation environment and it's not important to compile and upload from there. I'm aware that this might not be a feasible solution for everybody.

[popjelev]

Thank you for your swift reply and many thanks for writing this component. I'm searching for a solution for many weeks. I'm patient and in case something pops up I'll post it here (hope I find it).

[fabiopigi]

I'm having the same issue. ESPHome version v2022.9.2, installed via Docker (not HomeAssistant AddOn), on a raspberry 4 with Raspian 10 (buster).

[mmakaay]

Please try if adding these to your configuration YAML file fixes the issue:

esphome:
  platformio_options:
    platform_packages:
     - framework-espidf @ 3.40300.0

esp32:
  framework:
    type: esp-idf
    platform_version: 3.4.0

If you have used the example.yaml, then you should not have the esp32: and esphome: sections in your config. In that case, you can simply add the above config code to your YAML file. If you do have those in your existing config, then merge the options from above with your own config options for those sections.

[popjelev]

This changes solve the old issue, but a new one emerged :( and I can't figure out what to do :( Please help. Here's the compile log:

INFO Reading configuration /config/esphome/bedside-lamp-small-bedroom.yaml...
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@release/2021.10.0
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@release/2021.10.0
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing bedside-lamp-small-bedroom (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 3.4.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40300.0 (4.3.0) 
 - tool-cmake @ 3.16.9 
 - tool-ninja @ 1.10.2 
 - toolchain-riscv32-esp @ 8.4.0+2021r1 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r1 
 - toolchain-xtensa-esp32s2 @ 8.4.0+2021r1
Reading CMake configuration...
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
No dependencies
Compiling /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/src/main.o
Archiving /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/esp-idf/mdns/libmdns.a
Compiling /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/newlib/newlib_init.o
Compiling /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/newlib/time.o
Compiling /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/newlib/port/esp_time_impl.o
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:85:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_init'; did you mean '_lock_init'?
     ._retarget_lock_init = &__retarget_lock_init,
      ^~~~~~~~~~~~~~~~~~~
      _lock_init
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:86:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_init_recursive'; did you mean '_lock_init_recursive'?
     ._retarget_lock_init_recursive = &__retarget_lock_init_recursive,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      _lock_init_recursive
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:87:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_close'; did you mean '_lock_close'?
     ._retarget_lock_close = &__retarget_lock_close,
      ^~~~~~~~~~~~~~~~~~~~
      _lock_close
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:87:29: warning: initialization of 'void (*)(struct __lock **)' from incompatible pointer type 'void (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_close = &__retarget_lock_close,
                             ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:87:29: note: (near initialization for 's_stub_table._lock_close')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:88:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_close_recursive'; did you mean '_lock_close_recursive'?
     ._retarget_lock_close_recursive = &__retarget_lock_close_recursive,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      _lock_close_recursive
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:88:39: warning: initialization of 'void (*)(struct __lock **)' from incompatible pointer type 'void (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_close_recursive = &__retarget_lock_close_recursive,
                                       ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:88:39: note: (near initialization for 's_stub_table._lock_close_recursive')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:89:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_acquire'; did you mean '_lock_acquire'?
     ._retarget_lock_acquire = &__retarget_lock_acquire,
      ^~~~~~~~~~~~~~~~~~~~~~
      _lock_acquire
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:89:31: warning: initialization of 'void (*)(struct __lock **)' from incompatible pointer type 'void (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_acquire = &__retarget_lock_acquire,
                               ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:89:31: note: (near initialization for 's_stub_table._lock_acquire')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:90:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_acquire_recursive'; did you mean '_lock_acquire_recursive'?
     ._retarget_lock_acquire_recursive = &__retarget_lock_acquire_recursive,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      _lock_acquire_recursive
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:90:41: warning: initialization of 'void (*)(struct __lock **)' from incompatible pointer type 'void (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_acquire_recursive = &__retarget_lock_acquire_recursive,
                                         ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:90:41: note: (near initialization for 's_stub_table._lock_acquire_recursive')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:91:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_try_acquire'; did you mean '_lock_try_acquire'?
     ._retarget_lock_try_acquire = &__retarget_lock_try_acquire,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~
      _lock_try_acquire
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:91:35: warning: initialization of 'int (*)(struct __lock **)' from incompatible pointer type 'int (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_try_acquire = &__retarget_lock_try_acquire,
                                   ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:91:35: note: (near initialization for 's_stub_table._lock_try_acquire')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:92:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_try_acquire_recursive'; did you mean '_lock_try_acquire_recursive'?
     ._retarget_lock_try_acquire_recursive = &__retarget_lock_try_acquire_recursive,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      _lock_try_acquire_recursive
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:92:45: warning: initialization of 'int (*)(struct __lock **)' from incompatible pointer type 'int (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_try_acquire_recursive = &__retarget_lock_try_acquire_recursive,
                                             ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:92:45: note: (near initialization for 's_stub_table._lock_try_acquire_recursive')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:93:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_release'; did you mean '_lock_release'?
     ._retarget_lock_release = &__retarget_lock_release,
      ^~~~~~~~~~~~~~~~~~~~~~
      _lock_release
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:93:31: warning: initialization of 'void (*)(struct __lock **)' from incompatible pointer type 'void (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_release = &__retarget_lock_release,
                               ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:93:31: note: (near initialization for 's_stub_table._lock_release')
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:94:6: error: 'struct syscall_stub_table' has no member named '_retarget_lock_release_recursive'; did you mean '_lock_release_recursive'?
     ._retarget_lock_release_recursive = &__retarget_lock_release_recursive,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      _lock_release_recursive
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:94:41: warning: initialization of 'void (*)(struct __lock **)' from incompatible pointer type 'void (*)(struct __lock *)' [-Wincompatible-pointer-types]
     ._retarget_lock_release_recursive = &__retarget_lock_release_recursive,
                                         ^
/data/cache/platformio/packages/framework-espidf@3.40300.0/components/newlib/newlib_init.c:94:41: note: (near initialization for 's_stub_table._lock_release_recursive')
*** [/data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/newlib/newlib_init.o] Error 1
Compiling /data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/nghttp/nghttp2/lib/nghttp2_buf.o
========================= [FAILED] Took 34.15 seconds =========================

[mmakaay]

Oomph, that looks super nasty 😬 Thanks for the log, I'll dive into it.

[mmakaay]

Weird stuff really. Some define in the toolchain that doesn't seem to match the bundled compiled code for the framework in use. I managed to reproduce the issue and to do a build, but it took some hacking in the file framework-espidf@3.40300.0/components/newlib/newlib_init.c file. On line 84 I had to comment out the conflicting code:

// BEGINNING OF HACK BY @mmakaay
//#if _RETARGETABLE_LOCKING /* TODO: only if RETARGETABLE LOCKING IS IN ROM */
//    ._retarget_lock_init = &__retarget_lock_init,
//    ._retarget_lock_init_recursive = &__retarget_lock_init_recursive,
//    ._retarget_lock_close = &__retarget_lock_close,
//    ._retarget_lock_close_recursive = &__retarget_lock_close_recursive,
//    ._retarget_lock_acquire = &__retarget_lock_acquire,
//    ._retarget_lock_acquire_recursive = &__retarget_lock_acquire_recursive,
//    ._retarget_lock_try_acquire = &__retarget_lock_try_acquire,
//    ._retarget_lock_try_acquire_recursive = &__retarget_lock_try_acquire_recursive,
//    ._retarget_lock_release = &__retarget_lock_release,
//    ._retarget_lock_release_recursive = &__retarget_lock_release_recursive,
//#else
    ._lock_init = &_lock_init,
    ._lock_init_recursive = &_lock_init_recursive,
    ._lock_close = &_lock_close,
    ._lock_close_recursive = &_lock_close_recursive,
    ._lock_acquire = &_lock_acquire,
    ._lock_acquire_recursive = &_lock_acquire_recursive,
    ._lock_try_acquire = &_lock_try_acquire,
    ._lock_try_acquire_recursive = &_lock_try_acquire_recursive,
    ._lock_release = &_lock_release,
    ._lock_release_recursive = &_lock_release_recursive,
//#endif
// END OF HACK BY @mmakaay

I find a comparable "solution" at https://github.com/platformio/platform-espressif32/issues/646

[popjelev]

Thank you for your afford but unfortunately I cannot edit these files on my end. I'll try to experiment with different versions to see if build will pass. Also will see if there will be any replies in the issue you've mentioned.

[mmakaay]

I tried one of the suggestions there: cleaning the platformio directory. After doing that, the build is failing for me. So the combination of versions might just be a lucky fluke, once some other things were tried before, already filling up the platformio directory with "stuff".

[popjelev]

I've run build with different version of espidf framework and the results are:

framework-espidf @ 3.40300.0 [not working]
framework-espidf @ 3.40301.0 [working]
framework-espidf @ 3.40302.0 [not working]
framework-espidf @ 3.40401.0 [not working]
framework-espidf @ 3.40402.0 [not working]

So I think I'll stick with 3.40301.0 :) Many thanks for your time. I wasn't aware I can add such things in yaml. It's a mystery though why only one version is working but it's better than none :)

[mmakaay]

Oooh, I like that there is a [working] among those ;-) Gonna give that one a go too, see if we can find a clean way to make this build work. If yes, I will document it in the project.

[popjelev]

The build passes but doesn't work :( I mean I've flashed to my lamp but I cannot access it through Wi-Fi anymore or even power up. Even if I re-flash it through USB it doesn't react. If I try with ver4 of espidf ?

[mmakaay]

The build does work indeed, but I'm away from home so I cannot test if my produced firmware works or not when flashed to the lamp. I will try it when I get home.

[popjelev]

No worries - whenever you can. Thank you for your time once again.

[mmakaay]

Been doing some deep diving, because I was getting rather annoyed by the compilation issue :-p And I think I found an important piece of the puzzle.

The weird thing is if you go into the container and try to execute the compiler directly, you'll see the following:

# cd ~/.platformio/packages/toolchain-xtensa-esp32/bin
# ./xtensa-esp32-elf-gcc
bash: ./xtensa-esp32-elf-gcc: No such file or directory

That's a big "HUH?!", since the file is clearly there. Putting a strace on the execution does not provide much help:

# strace -f ./xtensa-esp32-elf-g++
execve("./xtensa-esp32-elf-g++", ["./xtensa-esp32-elf-g++"], 0xbee3cda4 /* 14 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

So this is something that misfires at a really low level. That lead me to inspecting the file structure.

# file xtensa-esp32-elf-gcc
xtensa-esp32-elf-gcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=e6ea21a3a86e4a7dbb90b1746d8baca4242abd72, stripped

The interpreter is /lib/ld-linux.so.3, but this system uses /lib/ld-linux-armhf.so.3 and does not have the configured interpreter! To test if this was the issue, I tried patching the binary to use the available interpreter instead:

# patchelf --set-interpreter /lib/ld-linux-armhf.so.3 xtensa-esp32-elf-gcc
# ./xtensa-esp32-elf-gcc
xtensa-esp32-elf-gcc: fatal error: no input files
compilation terminated.

The compiler became executable!! Another thing that I tried worked as well (using another broken binary to test the solution, since gcc was patched):

# ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
# ./xtensa-esp32-elf-g++
xtensa-esp32-elf-g++: fatal error: no input files
compilation terminated.

So this is a big lead. I'll now have to investigate if there is a clean way to have the ld-linux.so.3 interpreter installed on this system, or if it would mean that setting up a symlink has to be added to the docker container build.

[mmakaay]

Unfortunately, while adding the symlink makes the compiler work, the test program now fails at the linker stage. So it's interesting info, but no solution yet.

[popjelev]

Hope more people will look from the reopened issue at ESP Home repo. Fingers crossed :)

[mmakaay]

I tried installing esp-idf from Espressif on the raspberry. That installs a toolchain that looks like this:

# file ~/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
/root/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=fb6043a64c63d27f7ff239fc54e163fb5d06ed32, stripped

So looks like there actually is a toolchain for armhf. Question then is: why is that not used for the toolchain package that is installed by platformio.

[popjelev]

I've tried to build using different output formats from 3-Dots > Install > Manual download > Modern/Legacy format but also without success but I get different error if I use framework-espidf @ 3.40402.0 (latest):

INFO Reading configuration /config/esphome/bedside-lamp-small-bedroom.yaml...
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@release/2021.10.0
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing bedside-lamp-small-bedroom (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 3.4.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40402.0 (4.4.2) 
 - tool-cmake @ 3.16.9 
 - tool-ninja @ 1.10.2 
 - toolchain-riscv32-esp @ 8.4.0+2021r1 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r1 
 - toolchain-xtensa-esp32s2 @ 8.4.0+2021r1
Reading CMake configuration...
-- Building ESP-IDF components for target esp32
-- Configuring incomplete, errors occurred!
See also "/data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/CMakeFiles/CMakeOutput.log".

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/framework-espidf/tools/cmake/build.cmake:454 (message):
  /usr/bin/python3: Error while finding module specification for
  'idf_component_manager.prepare_components' (ModuleNotFoundError: No module
  named 'idf_component_manager')

Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:384 (idf_build_process)
  CMakeLists.txt:3 (project)

========================== [FAILED] Took 8.64 seconds ==========================

if I use framework-espidf @ 3.40401.0

INFO Reading configuration /config/esphome/bedside-lamp-small-bedroom.yaml...
INFO Updating https://github.com/mmakaay/esphome-xiaomi_bslamp2@release/2021.10.0
WARNING GPIO12 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing bedside-lamp-small-bedroom (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 3.4.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40401.0 (4.4.1) 
 - tool-cmake @ 3.16.9 
 - tool-ninja @ 1.10.2 
 - toolchain-riscv32-esp @ 8.4.0+2021r1 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r1 
 - toolchain-xtensa-esp32s2 @ 8.4.0+2021r1
Reading CMake configuration...
-- Found Git: /usr/bin/git (found version "2.30.2") 
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /data/cache/platformio/packages/toolchain-xtensa-esp32@8.4.0+2021r1/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32@8.4.0+2021r1/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32@8.4.0+2021r1/bin/xtensa-esp32-elf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32@8.4.0+2021r1/bin/xtensa-esp32-elf-g++
-- Check for working CXX compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32@8.4.0+2021r1/bin/xtensa-esp32-elf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32
-- Project sdkconfig file /config/esphome/.esphome/build/bedside-lamp-small-bedroom/sdkconfig.bedside-lamp-small-bedroom
/config/esphome/.esphome/build/bedside-lamp-small-bedroom/sdkconfig.bedside-lamp-small-bedroom:311 CONFIG_ESP32_REDUCE_PHY_TX_POWER was replaced with CONFIG_ESP_PHY_REDUCE_TX_POWER
/config/esphome/.esphome/build/bedside-lamp-small-bedroom/sdkconfig.bedside-lamp-small-bedroom:459 CONFIG_ESP_SYSTEM_PD_FLASH was replaced with CONFIG_ESP_SLEEP_POWER_DOWN_FLASH
/config/esphome/.esphome/build/bedside-lamp-small-bedroom/sdkconfig.bedside-lamp-small-bedroom:506 CONFIG_ESP32_PHY_CALIBRATION_AND_DATA_STORAGE was replaced with CONFIG_ESP_PHY_CALIBRATION_AND_DATA_STORAGE
/config/esphome/.esphome/build/bedside-lamp-small-bedroom/sdkconfig.bedside-lamp-small-bedroom:508 CONFIG_ESP32_PHY_MAX_WIFI_TX_POWER was replaced with CONFIG_ESP_PHY_MAX_WIFI_TX_POWER
/config/esphome/.esphome/build/bedside-lamp-small-bedroom/sdkconfig.bedside-lamp-small-bedroom:509 CONFIG_ESP32_PHY_MAX_TX_POWER was replaced with CONFIG_ESP_PHY_MAX_TX_POWER
-- Configuring incomplete, errors occurred!
See also "/data/bedside-lamp-small-bedroom/.pioenvs/bedside-lamp-small-bedroom/CMakeFiles/CMakeOutput.log".

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/framework-espidf@3.40401.0/tools/cmake/crosstool_version_check.cmake:37 (message):

  Toolchain:
  /data/cache/platformio/packages/toolchain-xtensa-esp32@8.4.0+2021r1/bin/xtensa-esp32-elf-gcc,
  crosstool-ng version esp-2021r1 doesn't match supported version
  esp-2021r2-patch3

  Please try to run 'idf.py fullclean' to solve it quickly.

  Check Getting Started documentation if the error continues.

  You can override this error and proceed with build by defining the
  IDF_MAINTAINER environment variable.

Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf@3.40401.0/components/esp_common/project_include.cmake:7 (crosstool_version_check)
  /data/cache/platformio/packages/framework-espidf@3.40401.0/tools/cmake/build.cmake:324 (include)
  /data/cache/platformio/packages/framework-espidf@3.40401.0/tools/cmake/build.cmake:537 (__build_process_project_includes)
  /data/cache/platformio/packages/framework-espidf@3.40401.0/tools/cmake/project.cmake:378 (idf_build_process)
  CMakeLists.txt:3 (project)

========================= [FAILED] Took 28.83 seconds =========================

Hope this helps you.

[mmakaay]

Summarized some knowledge at: https://github.com/esphome/issues/issues/3076#issuecomment-1277312765

[mmakaay]

I'll close this issue here, since it's somewhere on the ESPHome radar and it's not specific for the lamp firmware code.