Compatibility between "normal CMake" and ESP-IDF

Oleg Endo
Posts: 18
Joined: Fri Sep 28, 2018 1:48 pm

Re: Compatibility between "normal CMake" and ESP-IDF

Postby Oleg Endo » Sat Dec 15, 2018 2:30 pm

Is this line in idf_functions.cmake really required?

Code: Select all

    list(APPEND cxx_compile_options "-std=gnu++11" "-fno-rtti")
In particular "-fno-rtti" is a bit annoying when porting over c++ code. "-std=gnu++11" can be overridden in a project with standard cmake facilities like

Code: Select all

set (CMAKE_CXX_STANDARD 17)
set (CMAKE_CXX_STANDARD_REQUIRED 17)
set (CMAKE_CXX_EXTENSIONS OFF)
That will append "-std=c++17" after "-std=gnu++11" and everything's fine. Taking out the line in idf_function.cmake doesn't seem to make a difference, although perhaps that's because I'm not building all the components or something like that.

ESP_igrr
Posts: 2072
Joined: Tue Dec 01, 2015 8:37 am

Re: Compatibility between "normal CMake" and ESP-IDF

Postby ESP_igrr » Sat Dec 15, 2018 2:44 pm

Regarding c++ standard, see the comment here:
https://github.com/espressif/esp-idf/pu ... -171880574

Oleg Endo
Posts: 18
Joined: Fri Sep 28, 2018 1:48 pm

Re: Compatibility between "normal CMake" and ESP-IDF

Postby Oleg Endo » Sat Dec 15, 2018 2:46 pm

When setting up a build (i.e. running cmake for the first time) of a cmake project that links to some of my other libraries, on the first build I get this:

Code: Select all

Linking CXX executable test.elf
esp-idf/esp32/libesp32.a(crosscore_int.c.obj):(.iram1.literal+0xc): undefined reference to `_frxt_setup_switch'
esp-idf/esp32/libesp32.a(crosscore_int.c.obj): In function `esp_crosscore_isr':
~/esp/esp-idf/components/esp32/crosscore_int.c:67: undefined reference to `_frxt_setup_switch'
esp-idf/esp32/libesp32.a(dport_access.c.obj):(.literal.dport_access_init_core+0x14): undefined reference to `xt_ints_off'
esp-idf/esp32/libesp32.a(dport_access.c.obj):(.literal.dport_access_init_core+0x1c): undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(dport_access.c.obj): In function `dport_access_init_core':
~/esp/esp-idf/components/esp32/dport_access.c:169: undefined reference to `xt_ints_off'
~/esp/esp-idf/components/esp32/dport_access.c:171: undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(esp_timer.c.obj): In function `timer_alarm_handler':
~/esp/esp-idf/components/esp32/esp_timer.c:318: undefined reference to `_frxt_setup_switch'
esp-idf/esp32/libesp32.a(int_wdt.c.obj): In function `esp_int_wdt_cpu_init':
~/esp/esp-idf/components/esp32/int_wdt.c:96: undefined reference to `xt_ints_off'
~/esp/esp-idf/components/esp32/int_wdt.c:97: undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj):(.iram1.literal+0x8): undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj):(.iram1.literal+0x18): undefined reference to `xt_ints_off'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj):(.literal.is_vect_desc_usable+0x10): undefined reference to `_xt_interrupt_table'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj): In function `esp_intr_enable':
~/esp/esp-idf/components/esp32/intr_alloc.c:811: undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj): In function `esp_intr_disable':
~/esp/esp-idf/components/esp32/intr_alloc.c:851: undefined reference to `xt_ints_off'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj): In function `esp_intr_noniram_enable':
~/esp/esp-idf/components/esp32/intr_alloc.c:883: undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj): In function `ets_isr_unmask':
~/esp/esp-idf/components/esp32/intr_alloc.c:899: undefined reference to `xt_ints_off'
esp-idf/esp32/libesp32.a(intr_alloc.c.obj): In function `esp_intr_alloc_intrstatus':
~/esp/esp-idf/components/esp32/intr_alloc.c:650: undefined reference to `xt_ints_on'
esp-idf/esp32/libesp32.a(system_api.c.obj): In function `esp_restart_noos':
~/esp/esp-idf/components/esp32/system_api.c:272: undefined reference to `xt_ints_off'
esp-idf/newlib/libnewlib.a(locks.c.obj): In function `lock_acquire_generic':
~/esp/esp-idf/components/newlib/locks.c:146: undefined reference to `_frxt_setup_switch'
esp-idf/newlib/libnewlib.a(locks.c.obj): In function `lock_release_generic':
~/esp/esp-idf/components/newlib/locks.c:194: undefined reference to `_frxt_setup_switch'
esp-idf/freertos/libfreertos.a(port.c.obj):(.literal.pxPortInitialiseStack+0x8): undefined reference to `_xt_user_exit'
esp-idf/freertos/libfreertos.a(port.c.obj):(.literal.xPortStartScheduler+0x0): undefined reference to `_xt_coproc_init'
esp-idf/freertos/libfreertos.a(port.c.obj):(.literal.xPortStartScheduler+0x4): undefined reference to `_frxt_tick_timer_init'
esp-idf/freertos/libfreertos.a(port.c.obj):(.literal.xPortStartScheduler+0x8): undefined reference to `_frxt_dispatch'
esp-idf/freertos/libfreertos.a(port.c.obj):(.literal.vPortReleaseTaskMPUSettings+0x0): undefined reference to `_xt_coproc_release'
esp-idf/freertos/libfreertos.a(port.c.obj): In function `xPortStartScheduler':
~/esp/esp-idf/components/freertos/port.c:264: undefined reference to `_xt_coproc_init'
~/esp/esp-idf/components/freertos/port.c:268: undefined reference to `_frxt_tick_timer_init'
~/esp/esp-idf/components/freertos/port.c:276: undefined reference to `_frxt_dispatch'
esp-idf/freertos/libfreertos.a(port.c.obj): In function `vPortReleaseTaskMPUSettings':
~/esp/esp-idf/components/freertos/port.c:325: undefined reference to `_xt_coproc_release'
esp-idf/freertos/libfreertos.a(xtensa_intr.c.obj):(.literal.xt_set_interrupt_handler+0x4): undefined reference to `_xt_interrupt_table'
esp-idf/esp32/libesp32.a(cache_err_int.c.obj): In function `esp_cache_err_int_init':
~/esp/esp-idf/components/esp32/cache_err_int.c:37: undefined reference to `xt_ints_off'
~/esp/esp-idf/components/esp32/cache_err_int.c:63: undefined reference to `xt_ints_on'
collect2: error: ld returned 1 exit status
CMakeFiles/test.elf.dir/build.make:129: recipe for target 'test.elf' failed
make[3]: *** [test.elf] Error 1
CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/test.elf.dir/all' failed
make[2]: *** [CMakeFiles/test.elf.dir/all] Error 2
CMakeFiles/Makefile2:875: recipe for target 'esp-idf/CMakeFiles/flash.dir/rule' failed
make[1]: *** [esp-idf/CMakeFiles/flash.dir/rule] Error 2
Makefile:372: recipe for target 'flash' failed
After getting that initial link error, the issue can be fixed by doing

Code: Select all

make rebuild_cache
make
Seems to be some kind of link order issue of the IDF libraries/components?

ESP_igrr
Posts: 2072
Joined: Tue Dec 01, 2015 8:37 am

Re: Compatibility between "normal CMake" and ESP-IDF

Postby ESP_igrr » Sat Dec 15, 2018 2:49 pm

Can you please post the linker command line? In IDF all the component libraries are inside -Wl,-start_group, so theoretically linking order should not matter.

Oleg Endo
Posts: 18
Joined: Fri Sep 28, 2018 1:48 pm

Re: Compatibility between "normal CMake" and ESP-IDF

Postby Oleg Endo » Sat Dec 15, 2018 3:05 pm

Yeah, I know that IDF links its stuff in a link group, so I'm also a bit surprised. But I think I've seen this sometime before, don't remember on which occasion though (sorry, not helpful I know).

Code: Select all

Linking CXX executable test.elf
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/test.elf.dir/link.txt --verbose=1
~/esp/crosstool-NG/builds/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++  \
-mlongcalls  -nostdlib CMakeFiles/test.elf.dir/main.cpp.obj  \
-o test.elf \
dev/libdev.a \
utils/libutils.a \
hash/libhash.a \
fs/libfs.a \
-Wl,--gc-sections -Wl,--start-group esp-idf/soc/libsoc.a esp-idf/log/liblog.a \
esp-idf/heap/libheap.a esp-idf/xtensa-debug-module/libxtensa-debug-module.a \
esp-idf/app_trace/libapp_trace.a esp-idf/freertos/libfreertos.a \
esp-idf/vfs/libvfs.a esp-idf/newlib/libnewlib.a esp-idf/esp_ringbuf/libesp_ringbuf.a \
esp-idf/driver/libdriver.a esp-idf/esp_event/libesp_event.a esp-idf/ethernet/libethernet.a \
esp-idf/lwip/liblwip.a esp-idf/tcpip_adapter/libtcpip_adapter.a esp-idf/mbedtls/libmbedtls.a \
esp-idf/micro-ecc/libmicro-ecc.a esp-idf/bootloader_support/libbootloader_support.a \
esp-idf/spi_flash/libspi_flash.a esp-idf/app_update/libapp_update.a \
esp-idf/nvs_flash/libnvs_flash.a esp-idf/pthread/libpthread.a \
esp-idf/smartconfig_ack/libsmartconfig_ack.a esp-idf/wpa_supplicant/libwpa_supplicant.a \
esp-idf/esp32/libesp32.a esp-idf/cxx/libcxx.a -lgcov esp-idf/mbedtls/mbedtls/library/libmbedtls.a \
esp-idf/mbedtls/mbedtls/library/libmbedx509.a esp-idf/mbedtls/mbedtls/library/libmbedcrypto.a \
esp-idf/soc/libsoc.a esp-idf/log/liblog.a esp-idf/heap/libheap.a \
esp-idf/freertos/libfreertos.a -Wl,--undefined=uxTopUsedPriority esp-idf/newlib/libnewlib.a \
-L ~/esp/esp-idf/components/newlib/lib -lc-psram-workaround -lm-psram-workaround esp-idf/esp32/libesp32.a \
-L ~/esp/esp-idf/components/esp32/lib -lcoexist -lcore -lespnow -lmesh -lnet80211 \
-lphy -lpp -lrtc -lsmartconfig -lwpa2 -lwpa -lwps -L ~/code/test_sw/build_esp32/esp-idf/esp32 \
-T esp32_out.ld -T ~/code/test_sw/build_esp32/esp-idf/esp32/esp32.common.ld \
-L ~/esp/esp-idf/components/esp32/ld -T esp32.rom.ld -T esp32.peripherals.ld \
-T esp32.rom.libgcc.ld ~/esp/esp-idf/components/esp32/libhal.a -lgcc -u call_user_start_cpu0 \
-u ld_include_panic_highint_hdl esp-idf/cxx/libcxx.a -lstdc++ -u __cxa_guard_dummy -u esp_app_desc

esp-idf/esp32/libesp32.a(crosscore_int.c.obj):(.iram1.literal+0xc): undefined reference to `_frxt_setup_switch'
...
dev/libdev.a, utils/libutils.a, hash/libhash.a are some of my own libraries, which are added via target_link_libraries to the executable target before idf_import_components and idf_link_components. I've also tried adding my libraries after IDF components, but it doesn't make a difference. The error is the same.

ESP_igrr
Posts: 2072
Joined: Tue Dec 01, 2015 8:37 am

Re: Compatibility between "normal CMake" and ESP-IDF

Postby ESP_igrr » Sat Dec 15, 2018 3:11 pm

When the error happens, can you run xtensa-esp32-elf-nm on libfreertos.a and check if the functions reported in the error message are present in the archive?

Oleg Endo
Posts: 18
Joined: Fri Sep 28, 2018 1:48 pm

Re: Compatibility between "normal CMake" and ESP-IDF

Postby Oleg Endo » Sat Dec 15, 2018 3:25 pm

Let's start with the first one

Code: Select all

esp-idf/esp32/libesp32.a(crosscore_int.c.obj):(.iram1.literal+0xc): undefined reference to `_frxt_setup_switch'

Code: Select all

xtensa-esp32-elf-nm esp-idf/freertos/libfreertos.a | grep _frxt_setup_switch
         U _frxt_setup_switch
Others like xt_ints_off, xt_ints_on aren't present at all.

After running "make rebuild_cache && make" it will re-scan dependencies and re-build the following libraries/build targets: idf_component_freertos, idf_component_esp32

ESP_igrr
Posts: 2072
Joined: Tue Dec 01, 2015 8:37 am

Re: Compatibility between "normal CMake" and ESP-IDF

Postby ESP_igrr » Sat Dec 15, 2018 3:27 pm

Okay, what does "xtensa-esp32-elf-ar t libfreertos.a" say for the unsuccessful build? Any files missing compared to the successful one?

Oleg Endo
Posts: 18
Joined: Fri Sep 28, 2018 1:48 pm

Re: Compatibility between "normal CMake" and ESP-IDF

Postby Oleg Endo » Sat Dec 15, 2018 3:45 pm

Unsuccessful build:

Code: Select all

FreeRTOS-openocd.c.obj
croutine.c.obj
event_groups.c.obj
list.c.obj
port.c.obj
queue.c.obj
tasks.c.obj
timers.c.obj
xtensa_init.c.obj
xtensa_intr.c.obj
xtensa_overlay_os_hook.c.obj
Successful build:

Code: Select all

FreeRTOS-openocd.c.obj
croutine.c.obj
event_groups.c.obj
list.c.obj
port.c.obj
portasm.S.obj
queue.c.obj
tasks.c.obj
timers.c.obj
xtensa_context.S.obj
xtensa_init.c.obj
xtensa_intr.c.obj
xtensa_intr_asm.S.obj
xtensa_overlay_os_hook.c.obj
xtensa_vector_defaults.S.obj
xtensa_vectors.S.obj
The asm files are missing ......

Adding ASM to the list of languages of my exectuable project:

Code: Select all

project (test C CXX ASM)
fixes the problem it seems. That's a little inconvenient. I don't have any asm code in my project, why do I need to enable it in cmake? Looks like it should be enabled by the freertos library project, but it's not. ... ah, right, be cause all the IDF components are not actual cmake projects but they are just targets under the umbrella of the top-level project ...... or something like that? Hmm...

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: Compatibility between "normal CMake" and ESP-IDF

Postby ESP_Angus » Mon Dec 17, 2018 8:22 am

Oleg Endo wrote:
Sat Dec 15, 2018 3:45 pm
be cause all the IDF components are not actual cmake projects but they are just targets under the umbrella of the top-level project ...... or something like that? Hmm...
That's correct. Do you think a subproject would be more appropriate here?

Who is online

Users browsing this forum: No registered users and 72 guests