Unable to compile new firmware for BT Proxies

[Gferretta]

The problem

Hi everyone

Unfortunately I constantly receive these messages when trying to compile the new released versions of the BT Proxies on my RPi3b+. I was reading within the site that several have similar or similar errors that prevent the compilation, and the only way I have is through the website https://esphome.github.io/bluetooth-proxies/

I left referenced the error that I had posted in another post.

Thank you so much Regards

Which version of ESPHome has the issue?

2023.3.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.3.5

What platform are you using?

ESP32-IDF

Board

ESPRESSIF ESP32 CH9102X DUAL CORE WIFI BLUETOOTH

Component causing the issue

No response

Example YAML snippet

substitutions:
  name: esp32-bluetooth-proxy-059bf0
packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

Anything in the logs that might be useful for us?

Compilation error

INFO Reading configuration /config/esphome/esp32-bluetooth-proxy-059bf0.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing esp32-bluetooth-proxy-059bf0 (board: esp32dev; framework: espidf; platform: platformio/espressif32 @ 5.2.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-esp32ulp @ 2.35.0-20220830 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
Reading CMake configuration...
-- 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/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/esp32-bluetooth-proxy-059bf0/.pioenvs/esp32-bluetooth-proxy-059bf0/CMakeFiles/CMakeOutput.log".
See also "/data/esp32-bluetooth-proxy-059bf0/.pioenvs/esp32-bluetooth-proxy-059bf0/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/esp32-bluetooth-proxy-059bf0/.pioenvs/esp32-bluetooth-proxy-059bf0/CMakeFiles/CMakeTmp

    Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_0d3d7 && [1/2] Building C object CMakeFiles/cmTC_0d3d7.dir/testCCompiler.c.obj
    [2/2] Linking C executable cmTC_0d3d7
    FAILED: cmTC_0d3d7 
    : && /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -mlongcalls -Wno-frame-address   CMakeFiles/cmTC_0d3d7.dir/testCCompiler.c.obj  -o cmTC_0d3d7   && :
    /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: error loading plugin: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory
    collect2: error: ld returned 1 exit status
    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:296 (__project)
  CMakeLists.txt:3 (project)

========================= [FAILED] Took 21.61 seconds =========================

Originally posted by @Gferretta in https://github.com/esphome/esphome/discussions/4369#discussioncomment-5340127

### Additional information

_No response_

[nepozs]

Possible solution

esphome:
  name: ${name}
  name_add_mac_suffix: false
  compile_process_limit: 1

additional possibility - increase swap size

similar thread on the Polish-language forum https://forum.arturhome.pl/t/raspberry-pi-3b-i-esphome-przestroga/7444

[Gferretta]

Possible solution

esphome:
  name: ${name}
  name_add_mac_suffix: false
  compile_process_limit: 1

additional possibility - increase swap size

similar thread on the Polish-language forum https://forum.arturhome.pl/t/raspberry-pi-3b-i-esphome-przestroga/7444

Thank you for your attempt to help me. But it is not a problem of temperature or hang of the RPi3b+ Keep investigating. Regards

[Stooovie]

Same here. Stuck on 2022.12.6, unable to compile anything newer.

[nepozs]

@Gferretta @Stooovie It is not problem of temperature nor hang, I've said it in thread linked above It is problem of low RAM, so stopping all other Addons / containers could help. Second possibility is swap enlargement.

HAOS 10.0 will optimize swap management, so If you are brave enough you could switch HA to beta update channel, to test if it helps, as 10.0.rc1 is already published https://github.com/home-assistant/operating-system/releases/tag/10.0.rc1

PS To be safe I can suggest full backup and copy it in safe place before system update (just in case if something will go really wrong).

[ssieb]

It is problem of low RAM

It is not that. It's not even to the compiling stage.

[Stooovie]

thank but that seems unlikely. I run HA on a 2GB RPi4 which has usually almost a gig free. I can compile anything else (ESPHome), just not this BT proxy. I tried flashing via the web updater, but it failed upon "adapting" in HA in the same way.

[nepozs]

BT proxy uses huge amount of RAM during compilation (not comparable to any other project I've seen), so have you tried this?

esphome:
...
  compile_process_limit: 1

You could also

1. Clear Build Files and retry (it should help, if in reality 2GB RAM is really sufficient, I can't test if 2GB is enough because I use x64 configuration with 5 times more: 10GB of RAM)

2. Change framework from ESP-IDF back to Arduino (like in early BT proxy versions) it needs slightly smaller resources to compile, but with every framework change firmware must be flashed by serial, as it has different flash partitions, no OTA possible.

This type of change is not recommended due to BT proxy performance, but it could be temporary solution

esp32:
....
  framework:
    type: esp-idf

to

esp32:
....
  framework:
    type: arduino

BTW I've tested HAOS 10.0rc1 on my another x64 installation, and works

it is time of compilation on 10 gigs of ram

[Stooovie]

I have tried the compile process limit thing and clearing build files to no avail. I'll try the other methods and eventually report back. Thanks!

[nepozs]

Alternate way to install HAOS 10.0.rc1 (when beta channel activated, and possible update not displayed): ha os update --version 10.0.rc1 in case any problems (this version can't be treated as production ready, it is only way to test if problems are linked to RAM/swap) downgrade is possible the same way (backup mentioned earlier is just for safety) ha os update --version 9.5

BTW Nobody said a word about ESP32 boards used, but I suspect some kind of problem if board has IP101 Ethernet chip and ESP-IDF is used (I know about some problem when it is used in connection with BT proxy, but I don't have this hardware - there was some kind of problem with OTA - never succeeded with firmware compiled with 2023.2.x so standard way of Adpotion is not possible - Install step must be skipped, so better way is to prepare own YAML and compile yourself - it can be slightly modified YAML downloaded from project repo). I've no time to check if the problem also exist if Ethernet chip is LAN8720 but I probably will check this in next days using WT32-ETH01 board.

Compilation and firmware with BT proxy component (using current ESPHome 2023.3.1) tested so far in 2 WiFi-only configurations:

1. ESP-IDF and typical generic ESP32 (WiFi only board marked as Azdelivery kit v4, but it is in reality most generic ESP32 board))
2. Arduino and GL-S10 v1.0 (board with LAN8720 but not used in project, because device is mounted in place without wired Ethernet)

both cases working OK and OTA working OK

[ssieb]

@nepozs, did you look at the error message? It has nothing to do with RAM or the board he's using. It's a toolchain or container issue. I've seen other people with this error message, but I don't remember what the solution was or even if there was one.

[nepozs]

In fact it is tollchain erorr, idetical errors were generated if you try to compile on low-RAM machine (when RAM ends Supevisor kills proceses).

[Gferretta]

Hi nepozs

BT proxy uses huge amount of RAM during compilation (not comparable to any other project I've seen), so have you tried this?

esphome:
...
  compile_process_limit: 1

I tried this without satisfactory result

You could also

1. Clear Build Files and retry (it should help, if in reality 2GB RAM is really sufficient, I can't test if 2GB is enough because I use x64 configuration with 5 times more: 10GB of RAM)
2. Change framework from ESP-IDF back to Arduino (like in early BT proxy versions) it needs slightly smaller resources to compile, but with every framework change firmware must be flashed by serial, as it has different flash partitions, no OTA possible.

This type of change is not recommended due to BT proxy performance, but it could be temporary solution

esp32:
....
  framework:
    type: esp-idf

to

esp32:
....
  framework:
    type: arduino

Also but idem

BTW I've tested HAOS 10.0rc1 on my another x64 installation, and works

it is time of compilation on 10 gigs of ram

This not probed it

I think that this problem come from other things.

Thanks

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[diamant-x]

Hi, I'm facing this same issue today. I am able to install into my M5Stack Atom Lite the Bluetooth proxy firmware from https://esphome.github.io/bluetooth-proxies/ but then I'm unable to adopt it, because the device is within another subnet, and such config is not including this https://community.home-assistant.io/t/esp-devices-on-different-subnet-not-visible/464357/11 solution. So I tried installing in my RPI4 HAOS the ESPHome addon, and added the yaml code, but then the compilation process fails and I can't deploy it.

I'm seeing the same error described here: https://www.reddit.com/r/homeassistant/comments/zhwsy5/do_i_have_a_problem_i_have_a_problem_bluetooth/izoek85/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Any chance to make all libraries required for bluetooth-proxy compatible with arm64?

Home Assistant 2023.8.4 Supervisor 2023.08.1 Operating System 10.5 Frontend 20230802.1 - latest ESPHome Current version: 2023.8.2 rpi4-64bits 8GB RAM