Is it safe to build v4.3 or earlier versions using the 2021r1 gcc?

[axellin]

Hi,

I notice recent esp-idf update includes a new toolchain: esp-2021r1.
If I build esp-idf master with esp-2020r3, I got compile error:
/home/axel/esp/esp-idf/components/newlib/locks.c:240:23: error: invalid application of 'sizeof' to incomplete type 'struct __lock'
_Static_assert(sizeof(struct __lock) >= sizeof(StaticSemaphore_t),
^~~~~~
/home/axel/esp/esp-idf/components/newlib/locks.c:240:16: error: expression in static assertion is not an integer
_Static_assert(sizeof(struct __lock) >= sizeof(StaticSemaphore_t),
^~~~~~
/home/axel/esp/esp-idf/components/newlib/locks.c: In function '__retarget_lock_init':
/home/axel/esp/esp-idf/components/newlib/locks.c:286:11: warning: assignment to '_LOCK_T' {aka 'int'} from 'void *' makes integer from pointer without a cast [-Wint-conversion]
*lock = NULL; /* In case lock's memory is uninitialized */
^
/home/axel/esp/esp-idf/components/newlib/locks.c: In function '__retarget_lock_init_recursive':
/home/axel/esp/esp-idf/components/newlib/locks.c:292:11: warning: assignment to '_LOCK_T' {aka 'int'} from 'void *' makes integer from pointer without a cast [-Wint-conversion]
*lock = NULL; /* In case lock's memory is uninitialized */
^
In file included from ../../../../../components/esp_common/include/esp_err.h:18,
from ../../../../../components/hal/include/hal/cpu_hal.h:20,
from ../../../../../components/esp_hw_support/include/esp_cpu.h:22,
from ../../../../../components/esp_hw_support/include/soc/cpu.h:22,
from /home/axel/esp/esp-idf/components/newlib/locks.c:19:
/home/axel/esp/esp-idf/components/newlib/locks.c: In function 'check_lock_nonzero':
/home/axel/esp/esp-idf/components/newlib/locks.c:309:17: warning: comparison between pointer and integer
assert(lock != NULL && "Uninitialized lock used");
^~
../../../../../components/newlib/platform_include/assert.h:44:42: note: in definition of macro 'assert'
#define assert(__e) (__builtin_expect(!!(__e), 1) ? (void)0 : __assert_func (__FILE__, __LINE__, \
^~~
[560/987] Building C object esp-idf/freertos/CMakeFiles/__idf_freertos.dir/tasks.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

So I have no choice but to upgrade to esp-2021r1.

I use git to switch branches and it's not clear to me about the toolchain version v.s. esp-idf version.
My question is "Is it safe to use esp-2021r1 to build other branches? e.g. v4.3 or v4.2".
What is fixed in esp-2021r1? I cannot find release note for the toolchain update.

[axellin]

Oh.. Just try it..
Use 2021r1 gcc in v4.3 will cause build errors:

/home/axel/esp/esp-idf/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
/home/axel/esp/esp-idf/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
/home/axel/esp/esp-idf/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
...

[axellin]

If the trend is to migrate to the latest 2021r1 gcc, I hope this migration
for other branches will be done ASAP.
It's really very inconvenience that switching branches needs to re-install
different version of toolchain.

[ESP_Angus]

If the trend is to migrate to the latest 2021r1 gcc, I hope this migration
for other branches will be done ASAP.
It's really very inconvenience that switching branches needs to re-install
different version of toolchain.

We will update the 2021r1 toolchain on the release/v4.3 branch but not on the other branches.

You shouldn't need to re-install the toolchain each time though, running export.sh script (or equivalent) again after changing branches should be enough. It will find the correct toolchain version and set the PATH for it.

EDIT: First version of this post incorrectly said install.sh

[axellin]

We will update the 2021r1 toolchain on the release/v4.3 branch but not on the other branches.

You shouldn't need to re-install the toolchain each time though, running install.sh script (or equivalent) again after changing branches should be enough. It will find the correct toolchain version and set the PATH for it.

Actually, I already tried it. After switching from master to v4.3 branch and running install.sh in v4.3, my toolchain is still 2021r1.

[axellin]

Actually, I already tried it. After switching from master to v4.3 branch and running install.sh in v4.3, my toolchain is still 2021r1.

After running install.sh , I need to run export.sh again to make it work.

[ESP_Angus]

Sorry, I meant to write "export.sh". I'll edit my post for future readers.

The other thing is that CMake saves the current toolchain path inside the build directory, so it's necessary to run "idf.py fullclean" or delete the build directory after changing toolchain versions in a single project. We're working on a idf.py feature to detect this case.

[axellin]

Where is the release note for the new toolchain?
I want to figure out what is fixed/improved by 2021r1 toolchain?

[XiotSamuel]

I also have similar problem. After I reinstall VScode and install the ESP-extension and run the "config ESP extension" then "install ESP-MDF", I found I am still cannot build my previous project and stuck in new lib. Any one have idea how to troubleshoot this?

Code: Select all

\esp\.espressif\esp-mdf\esp-idf\components\newlibs
'struct syscall_stub_table' has no member named '_retarget_lock_init'; did you mean '_lock_init'?
'struct syscall_stub_table' has no member named '_retarget_lock_acquire_recursive'; did you mean '_lock_acquire_recursive'?
'struct syscall_stub_table' has no member named '_retarget_lock_close'; did you mean '_lock_close'?
'struct syscall_stub_table' has no member named '_retarget_lock_close_recursive'; did you mean '_lock_close_recursive'?
'struct syscall_stub_table' has no member named '_retarget_lock_acquire'; did you mean '_lock_acquire'?
'struct syscall_stub_table' has no member named '_retarget_lock_acquire_recursive'; did you mean '_lock_acquire_recursive'?
'struct syscall_stub_table' has no member named '_retarget_lock_try_acquire'; did you mean '_lock_try_acquire'?
'struct syscall_stub_table' has no member named '_retarget_lock_try_acquire_recursive'; did you mean '_lock_try_acquire_recursive'?
'struct syscall_stub_table' has no member named '_retarget_lock_release'; did you mean '_lock_release'?
'struct syscall_stub_table' has no member named '_retarget_lock_release_recursive'; did you mean '_lock_release_recursive'?

[dfrenkel]

Was anyone able to get this fixed?