api services remote_transmitter compile error esp32c3 #2 #3564

paccerdk · 2022-09-08T03:02:44Z

The problem

Getting undefined reference when using lambda

Seems that stale bot is closing a lot of issues in this repo that should not be closed - I've come across this a lot in this repo., this time, came here from google, with same problem.

original issue: #3201

one thing i'm noticing is that i use esp32-c3 too, in this case, with esp-idf however.

Which version of ESPHome has the issue?

ESPHome version 2022.8.3 compiled on Sep 7 2022, 22:10:13

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.8.7

What platform are you using?

ESP-IDF

Board

ESP-C3-12F custom hardware

Component causing the issue

api service lambda

Example YAML snippet

esphome:
  name: espinfra1
  platformio_options:
    board_build.flash_mode: dio
    
esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:
  services:
    - service: send_ir_raw
      variables:
        keycode: int[]
      then:
      - remote_transmitter.transmit_raw:
          transmitter_id: IR_TX
          code: !lambda 'return keycode;'
          carrier_frequency: 38kHz

ota:
  password: "xxxxxxxxxxx"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
          
remote_transmitter:
  - id: IR_TX
    pin: GPIO3
    carrier_duty_percent: 50%
  - id: dummy #workaround for issue: https://github.com/esphome/issues/issues/2934 
    pin: GPIO0
    carrier_duty_percent: 50%

  
remote_receiver:
  pin:
    number: GPIO4
    inverted: true
  dump: all

Anything in the logs that might be useful for us?

INFO Reading configuration /config/esphome/espinfra1.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing espinfra1 (board: esp32-c3-devkitm-1; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32C3 160MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40302.0 (4.3.2) 
 - tool-cmake @ 3.16.4 
 - tool-ninja @ 1.7.1 
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch2 
 - toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2
Reading CMake configuration...
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
No dependencies
Compiling /data/espinfra1/.pioenvs/espinfra1/src/main.o
Linking /data/espinfra1/.pioenvs/espinfra1/firmware.elf
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/espinfra1/.pioenvs/espinfra1/src/main.o: in function `esphome::api::ListEntitiesServicesArgument::ListEntitiesServicesArgument()':
/config/esphome/.esphome/build/espinfra1/src/esphome/components/api/api_pb2.h:786: undefined reference to `esphome::api::enums::ServiceArgType esphome::api::to_service_arg_type<std::vector<long, std::allocator<long> > >()'
collect2: error: ld returned 1 exit status
*** [/data/espinfra1/.pioenvs/espinfra1/firmware.elf] Error 1
========================= [FAILED] Took 21.36 seconds =========================

waicool20 · 2022-09-18T21:08:46Z

Similar issue but I got a bit more in the log

HARDWARE: ESP32C3 160MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40302.0 (4.3.2) 
 - tool-cmake @ 3.16.4 
 - tool-ninja @ 1.7.1 
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch2 
 - toolchain-xtensa-esp32s2 @ 8.4.0+2021r2-patch2
Reading CMake configuration...
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- noise-c @ 0.1.4
|   |-- libsodium @ 1.10018.1
Compiling /data/test/.pioenvs/test/src/main.o
Linking /data/test/.pioenvs/test/firmware.elf
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/test/.pioenvs/test/src/main.o: in function `esphome::api::ExecuteServiceArgument* std::__uninitialized_copy<false>::__uninit_copy<__gnu_cxx::__normal_iterator<esphome::api::ExecuteServiceArgument const*, std::vector<esphome::api::ExecuteServiceArgument, std::allocator<esphome::api::ExecuteServiceArgument> > >, esphome::api::ExecuteServiceArgument*>(__gnu_cxx::__normal_iterator<esphome::api::ExecuteServiceArgument const*, std::vector<esphome::api::ExecuteServiceArgument, std::allocator<esphome::api::ExecuteServiceArgument> > >, __gnu_cxx::__normal_iterator<esphome::api::ExecuteServiceArgument const*, std::vector<esphome::api::ExecuteServiceArgument, std::allocator<esphome::api::ExecuteServiceArgument> > >, esphome::api::ExecuteServiceArgument*)':
/data/cache/platformio/packages/toolchain-riscv32-esp/riscv32-esp-elf/include/c++/8.4.0/bits/stl_uninitialized.h:82: undefined reference to `long esphome::api::get_execute_arg_value<long>(esphome::api::ExecuteServiceArgument const&)'
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/test/.pioenvs/test/src/main.o: in function `esphome::api::ListEntitiesServicesArgument::ListEntitiesServicesArgument()':
/data/cache/platformio/packages/toolchain-riscv32-esp/riscv32-esp-elf/include/c++/8.4.0/bits/stl_vector.h:1085: undefined reference to `esphome::api::enums::ServiceArgType esphome::api::to_service_arg_type<long>()'

github-actions · 2023-01-17T01:56:46Z

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.

paccerdk · 2023-01-18T01:18:57Z

bug still present

CarlosGS · 2023-03-15T11:38:22Z

I confirm this is still an issue with ESP32C3, in this case using Arduino idf (haven't tried with esp-idf).

/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/co2portable/.pioenvs/co2portable/src/main.cpp.o: in function `esphome::api::ExecuteServiceArgument* std::__uninitialized_copy<false>::__uninit_copy<__gnu_cxx::__normal_iterator<esphome::api::ExecuteServiceArgument const*, std::vector<esphome::api::ExecuteServiceArgument, std::allocator<esphome::api::ExecuteServiceArgument> > >, esphome::api::ExecuteServiceArgument*>(__gnu_cxx::__normal_iterator<esphome::api::ExecuteServiceArgument const*, std::vector<esphome::api::ExecuteServiceArgument, std::allocator<esphome::api::ExecuteServiceArgument> > >, __gnu_cxx::__normal_iterator<esphome::api::ExecuteServiceArgument const*, std::vector<esphome::api::ExecuteServiceArgument, std::allocator<esphome::api::ExecuteServiceArgument> > >, esphome::api::ExecuteServiceArgument*)':
/data/cache/platformio/packages/toolchain-riscv32-esp/riscv32-esp-elf/include/c++/8.4.0/bits/stl_uninitialized.h:82: undefined reference to `long esphome::api::get_execute_arg_value<long>(esphome::api::ExecuteServiceArgument const&)'
/data/cache/platformio/packages/toolchain-riscv32-esp/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld: /data/co2portable/.pioenvs/co2portable/src/main.cpp.o: in function `esphome::api::ListEntitiesServicesArgument::ListEntitiesServicesArgument()':
/config/esphome/.esphome/build/co2portable/src/esphome/components/adc/adc_sensor.h:17: undefined reference to `esphome::api::enums::ServiceArgType esphome::api::to_service_arg_type<long>()'
collect2: error: ld returned 1 exit status

It only happens when enabling services:, removing that part allows to compile correctly.

CarlosGS · 2023-03-28T12:33:29Z

@agners Please help us out, this issue is related to what you saw here esphome/esphome#2035 (comment). The linker gets confused by the different types and gives an error when enabling api user services.

The error goes away by changing int32_t to long (esphome/esphome@dev...CarlosGS:esphome:patch-48), but the API stops working. In general, I don't understand this part well enough to make a proper PR. Maybe it is possible to re-define the int32_t earlier, or maybe it is something else. Hoping you can have a go at it. Thanks! :)

agners · 2023-03-28T15:02:15Z

Can't you just define it using int, e.g.

template<> std::vector<int> get_execute_arg_value<std::vector<int>>(const ExecuteServiceArgument &arg) {

Honestly, I am also not sure as to why RISC-V defines uint32_t differently.

agners · 2023-03-28T15:03:40Z

Hm, that would essentially revert my change 🤔 Yeah, not sure 😰

CarlosGS · 2023-03-28T21:28:44Z

Thanks! No worries, I was just hoping it'd be something more evident 😄
Unfortunately Espressif has adopted this oddity for Xtensa too: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.0/gcc.html#int32-t-and-uint32-t-for-xtensa-compiler & espressif/esp-idf#9511 (comment).

Another issue caused by this: #3970

For the api services, I've tried just swapping all int to int32_t CarlosGS/esphome@a07ad7f, in line with your change, and it compiles without errors/warnings. But the API stops working even for the normal HASS connection.
The compilation is clean & USB logging doesn't show anything relevant with VERY_VERBOSE (sensors & OTA work OK, just no API). And on the HASS side, logs just show Connection error occurred: [Errno 104] Connection reset by peer.

Thanks for having a look. Can't do much more at the moment either, but it's good to keep an eye on that annoying change.

agners · 2023-03-29T07:11:08Z

Unfortunately Espressif has adopted this oddity for Xtensa too: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.0/gcc.html#int32-t-and-uint32-t-for-xtensa-compiler & espressif/esp-idf#9511 (comment).

Well, I guess it is a good thing in the end, as it matches now and it seems to be what upstream GCC is doing. But yeah, the change is annoying at first 😅

But the API stops working even for the normal HASS connection.

I mean it didn't compile before, so "stops working" sounds weird to me?

CarlosGS · 2023-03-29T07:28:34Z

Good point! Well the linker error mentioned in this thread only appears when adding services: to the api section.

I meant when changing user_services.cpp to turn all int to int32_t, there are no linker errors anymore, but the api connection now doesn't work (with or without services: enabled in YAML).

twosky2000 · 2023-04-24T03:52:14Z

here's my fix:


esphome:
  name: fingerprint
  platformio_options:
    board_build.flash_mode: dio
    board_build.extra_flags:
      #- "-DARDUINO_USB_MODE=0"
      - "-DARDUINO_USB_CDC_ON_BOOT=0"
      - "-include \"fix.h\""

file at .esphome/build/fingerprint/fix.h


#ifdef __riscv

#undef __INT32_TYPE__
#define __INT32_TYPE__      int

#undef __UINT32_TYPE__
#define __UINT32_TYPE__     unsigned int

#endif // __riscv

I got the idea from
espressif/esp-idf#6906
https://github.com/arendst/Tasmota/pull/11808/commits

seams esp-idf assumes int is int long for RISC-V/esp32-3c. Maybe PlatformIO can use this fix too.

I try to make a pr when I figure out how to make this automatic.

mkaiser · 2023-08-11T21:12:57Z

`

here's my fix:
esphome:
  name: fingerprint
  platformio_options:
    board_build.flash_mode: dio
    board_build.extra_flags:
      #- "-DARDUINO_USB_MODE=0"
      - "-DARDUINO_USB_CDC_ON_BOOT=0"
      - "-include \"fix.h\""
file at .esphome/build/fingerprint/fix.h
#ifdef __riscv

#undef __INT32_TYPE__
#define __INT32_TYPE__      int

#undef __UINT32_TYPE__
#define __UINT32_TYPE__     unsigned int

#endif // __riscv
I got the idea from espressif/esp-idf#6906 https://github.com/arendst/Tasmota/pull/11808/commits

seams esp-idf assumes int is int long for RISC-V/esp32-3c. Maybe PlatformIO can use this fix too.

I try to make a pr when I figure out how to make this automatic.

thank you very much for this hotfix, got my stuff working now, after several headaches ;)

@esp Core developers: Is there any chance you can "really fix" this datatype interpretation issue?

clomads · 2023-08-29T22:37:01Z

I can also confirm the hotfix works

CarlosGS · 2023-11-21T20:06:09Z

Here's the updated patch, after the .esphome build folder was moved in esphome/esphome#5374

Create the file fix.h mentioned above, but now place it in the main esphome folder (next to the yaml files).
In the yaml code you need to add src/ and additional includes: statement:

esphome:
  name: theName
  platformio_options:
    board_build.extra_flags:
      - "-include \"src/fix.h\""
  includes:
    - fix.h

This way the fix.h file is automatically copied into the src/ folder within the platformio build directory.

babgvant · 2024-01-23T21:18:33Z

Here's the updated patch, after the .esphome build folder was moved in esphome/esphome#5374
* Create the file `fix.h` mentioned above, but now place it in the main esphome folder (next to the yaml files).

* In the yaml code you need to add `src/` and additional `includes:` statement:
esphome:
  name: theName
  platformio_options:
    board_build.extra_flags:
      - "-include \"src/fix.h\""
  includes:
    - fix.h
This way the fix.h file is automatically copied into the src/ folder within the platformio build directory.

Thank you! This worked for me as well with a ESP-C3-Zero board.

CarlosGS · 2024-04-05T21:11:14Z

Not sure when or how, but this seems to be already fixed 🎉
Anyone else can confirm it is possible to compile without the patch?

liwei19920307 mentioned this issue Oct 28, 2022

Please fix api bug Jorre05/remote_receiver#1

Open

github-actions bot added the stale label Jan 17, 2023

github-actions bot removed the stale label Jan 18, 2023

segfly mentioned this issue Jan 26, 2023

ESP32 ledc not dimming or turning off display after upgrade to 2022.12.0 #3925

Open

CarlosGS mentioned this issue Jul 27, 2023

Swap ADC back to use 'int' because C3 esphome/esphome#5151

Merged

11 tasks

CarlosGS mentioned this issue Nov 21, 2023

ESPhome 2023.7.0 compile with api/services failed #4729

Open

RagingCub mentioned this issue Jan 17, 2024

Bootloop when adding remote_transmitter on esp s3 mini #5400

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

api services remote_transmitter compile error esp32c3 #2 #3564

api services remote_transmitter compile error esp32c3 #2 #3564

paccerdk commented Sep 8, 2022 •

edited

waicool20 commented Sep 18, 2022

github-actions bot commented Jan 17, 2023

paccerdk commented Jan 18, 2023 •

edited

CarlosGS commented Mar 15, 2023

CarlosGS commented Mar 28, 2023 •

edited

agners commented Mar 28, 2023

agners commented Mar 28, 2023

CarlosGS commented Mar 28, 2023

agners commented Mar 29, 2023

CarlosGS commented Mar 29, 2023

twosky2000 commented Apr 24, 2023 •

edited

mkaiser commented Aug 11, 2023

clomads commented Aug 29, 2023

CarlosGS commented Nov 21, 2023

babgvant commented Jan 23, 2024

CarlosGS commented Apr 5, 2024

api services remote_transmitter compile error esp32c3 #2 #3564

api services remote_transmitter compile error esp32c3 #2 #3564

Comments

paccerdk commented Sep 8, 2022 • edited

The problem

Which version of ESPHome has the issue?

What type of installation are you using?

Which version of Home Assistant has the issue?

What platform are you using?

Board

Component causing the issue

Example YAML snippet

Anything in the logs that might be useful for us?

waicool20 commented Sep 18, 2022

github-actions bot commented Jan 17, 2023

paccerdk commented Jan 18, 2023 • edited

CarlosGS commented Mar 15, 2023

CarlosGS commented Mar 28, 2023 • edited

agners commented Mar 28, 2023

agners commented Mar 28, 2023

CarlosGS commented Mar 28, 2023

agners commented Mar 29, 2023

CarlosGS commented Mar 29, 2023

twosky2000 commented Apr 24, 2023 • edited

mkaiser commented Aug 11, 2023

clomads commented Aug 29, 2023

CarlosGS commented Nov 21, 2023

babgvant commented Jan 23, 2024

CarlosGS commented Apr 5, 2024

paccerdk commented Sep 8, 2022 •

edited

paccerdk commented Jan 18, 2023 •

edited

CarlosGS commented Mar 28, 2023 •

edited

twosky2000 commented Apr 24, 2023 •

edited