undefined reference to memcpy, memmove, memset, ...

[jumjum123]

Just downloaded latest ESP-IDF.
During linking with my make, I get an undefined reference error for memcpy, memmove, memset, memcmp, and strcmp, strcpy
This was not the case with ESP-IDF about a week ago.
Is there anything new in actual download ?

[kolban]

Howdy,
Just a thought ... knowing the project you are working with, I believe you are working with a custom "Makefile" building apps. Specifically, you are performing your own link in your own custom Makefile. The ESP-IDF provides its own "build system" that happens "under the covers" through the ESP-IDF Makefile. ESP-IDF releases may change the libraries that are linked and your own custom Makefile will have to replicate those changes to be consistent.

Again ... just a guess.

[jumjum123]

Hello Neil,

yes, I'm still working on Espruino.
Already had some problems with new heap component, but this is solved.

Problem is to find out, which library (or whatever) needs to be involved.
Any idea, how to check this ?

Right now compiling runs fine, after adding libc-psram-workaround.a. Thats based on guess, trial and error
Sounds good, but now it does not start Espruoino anymore

[ESP_Angus]

I think I saw this as well recently with partial builds after an update, there's an intermediate build file that isn't being regenerated like it should.

"make clean" and then building again should solve it, you shouldn't need to hack up any IDF files.

If it's still broken, let us know and we'll try and take a look at your project.

[jumjum123]

Thanks for the feedback, downloaded latest version from github and still got undefined reference

Next added
-T(ESP_IDF_PATH)/components/esp32/ld/esp32.rom.spiram_incompatible_fns.ld
Now got undefined reference for esp_pthread_init

Next added
-L$(ESP_APP_TEMPLATE_PATH)/build/pthread \
-I$(ESP_IDF_PATH)/components/pthread/include \
-lheap \
Compiling runs fine. Size of binary is about 30k less than before.

Uploaded to ESP Board and it works, at least with simple test.

Would there be any way to find changes like this, instead of my simple textsearch, trial & error ?

[kolban]

One way would be to write a simple ESP-IDF application using the Espressif ESP-IDF build system. You can then set the environment variable V=1 and run the build system. This will produce a detailed description of all the flags passed to the compile when the C code is compiled and all the linked flags passed to the linker when the link step is performed. From this, you can reverse engineer the flags that the ESP-IDF build system is using.

To the best of my knowledge, the "internals" of the build system supplied be ESP-IDF aren't documented/broken apart and the high level expectation is to use the build environment to create ESP32 applications. That said, there should be no mystery nor magic in the build meaning that if you write your own scripts or build your own Makefile that does the same as the ESP-IDF build system, you should be just fine.

To perform "regression" checks, get yourself to a working environment and take a copy of the Makefiles necessary to build a regular ESP-IDF environment. Put them somewhere safe. Now, when ever you grab a new copy of the master ESP-IDF, you can perform a file diff against those few files and the ones you had saved when it was working. That way you will at least be "made aware" when a change is made to the build environment so that you can reflect any necessary changes back into your own build environment.

[jumjum123]

@nkolban,
thanks, for the idea.We have a wording for what happens to me from time to time.

Sometimes you cannot see the wood, because of all the trees

[ESP_Sprite]

Jumjum123: Hehe, either you're Dutch or multiple languages developed the same saying

[jumjum123]

@ESP_Sprite,
good guess, its Germany close to Venlo

[kolban]

I'm Scottish ... I grew up with that one too ... see:

https://www.englishclub.com/ref/esl/Idi ... es_148.htm

https://ell.stackexchange.com/questions ... -come-from


Apparently a reference was found in 1546 ...

http://www.phrases.org.uk/bulletin_boar ... s/630.html