ESP32 Forum

With latest source from github I get the warning above.
This was not the case with previous version (2 weeks old).

In our project we have to use our own makefile.
Is there any lib which needs to be added or any other file/flag/what_ever ?
Where is _start defined ?

Thanks for your help in advance

@jumjum123,
What I find is that when we build with the ESP32 supplied make/build system, all seems to compile cleanly with the latest github environment. If you are using your own Makefile, what I would recommend is building a sample ESP-IDF based template application and switch on verbose output. That will show you each and every flag passed to the compiler and linker. For each of those, compare those against what you were previously using. I suspect that you will find a difference.

At present, there isn't any "formal documentation" that I am aware of that describes exactly what flags and options (and their orders) are required to hand compile an ESP32 application ... but thankfully, there doesn't appear to be any black-magic in the utilization of the tool chains other than generating a sample compile, creating a spreadsheet of all the options used and replicating them in your own build environment.

jumjum123 wrote:With latest source from github I get the warning above.
This was not the case with previous version (2 weeks old).

In our project we have to use our own makefile.
Is there any lib which needs to be added or any other file/flag/what_ever ?
Where is _start defined ?

_start is the default entry point for gcc's linker. It's not used in esp-idf, the linker scripts (in components/esp32/ld/) override it to call_start_cpu0. So this implies your custom Makefile linker step is not passing the correct linker arguments. If you build an esp-idf example as "make V=1", then you'll see the full linker command line as part of the verbose output (it's quite long!)

I'm very interested to know the reasons why you need your own Makefile. If there's anything we can do to make integrating with your build process easier (or supporting your use case in esp-idf), we'd be happy to consider it.

Thanks to kolban and ESP_ANGUS,
I will take this as a starting point.
Another guy(wilberforce) found a first hack by copy files
from: copy esp32\template\components\arduino-esp32\tools\sdk\lib libs
to:esp32\esp-idf\components\esp32\lib
Problem seems to be somewhere around Arduino libs (?)
Hopefully we will get rid of arduino libs, once we have V2 with support for I2C and SPI

@ESP_ANGUS, we are working on a port to get Javascript(Espruino) running on ESP32.
There is a huge makefile handling a lot of different sources and options, which is maintained by the owner(gordon williams)
Support of core for new functions and in case of bugs is great.
Right now I see only 2 options:
- check makefile in Espruino after each change in esp-idf (which was extended for ESP32 by kolban some months ago)
- convert everything to be a component in esp-idf and check after each change in Espruino
First option worked fine up to now, second option would result in a lot of work, at least to get it running first
See make file, please take a look to https://github.com/espruino/Espruino/bl ... 2/Makefile

If you would like to get some more info, please drop me a line

The "Cannot find symbol" errors generally occur when you try to reference an undeclared variable in your code. A "Cannot find symbol" error means that the compiler cannot do this. Your code appears to be referring to something that the compiler doesn't understand.

The general causes for a Cannot find symbol error are things like:

Incorrect spelling.
Wrong case. Halo is different from halo.
Improper use of acceptable identifier values (letters, numbers, underscore, dollar sign), my-class is not the same as myclass.
No variable declaration or variable is outside of the scope you are referencing it in.