Symbol defined in multiple locations (IDFGH-14468) #15242
Comments
github-actions
bot
changed the title
|
@chegewara Could you please add some instruction for reproducing this issue? (IDF version, project you are compiling, chip you are compiling for, what does the idf_component.yml file look like, and so on) I guess you may be missing a condition to only add this component for the chips which don't have built-in Wi-Fi, like esp-idf/examples/wifi/iperf/main/idf_component.yml Lines 12 to 13 in 0f0068f but hard to tell exactly without knowing more details. |
|
Hi @igrr
From this single example im guessing that BTW i just found some inconsistency in menuconfig, no idea why (it is from esp-idf ble mesh example with added support for P4; code can build and firmware working): Thanks |
|
Another conflict example is between esp-idf wifi component and esp_wifi_remote component when using it with esp32-p4 In this case i believe some Kconfig checks are missing in esp-idf wifi component. There is more like this. |
|
Thanks for reporting, we will look into this. The issue is that symbols defined under native Wi-Fi component get duplicated by the injected symbols from the wifi-remote component. The definitions are mutually exclusive (i.e. either defined inside different |
|
Hello @chegewara! Just to complement my colleagues, this is caused by the new esp-idf-kconfig functionality introduced in https://github.com/espressif/esp-idf-kconfig/releases/tag/v2.4.0, reporting potential issues when one config name is defined in multiple locations. I am already working on a better output of this, sorry for the inconvenience. |
|
Hi,
Thanks PS the problem i have is espressif team attitude sometimes |
|
I'll try to answer you in detail. TLDR:
Yes, configuration system per-se allows multiple config name definition. But it is very error prone and we would like to highlight situations when it happens.
As a user; report to the affected component and let its developers to fix it.
It depends on the order in which Kconfig files are loaded. The process is deterministic, but unclear for humans. Multiple definitions are "half-merged" together (e.g. help and prompt are preserved for every definition).
That's the problem. In parse time, we generally cannot tell which config option is inactive and which value (from which location) it will get. To be extra safe, I opted to report all multiple definitions, which unfortunately flooded the output. Detailed answer: I'll start very widely; kconfig configuration system per-se allows multiple definitions of the same symbol name and there may be use cases which cannot be (easily) solved by other means (e.g. you need to redefine a config option from third party component for your specific use). The process of which Kconfig file is loaded in which order (and thus which location will be the last one) is set by the relationships between Kconfig files (via To prevent this, I'll implement a a way how the component developers will be able to mark some config options as allowed to be set multiple times. Then, they will have a mean to restrict the number of these info statements to the minimum. I hope I answered your question sufficiently. All of this will be described in greater detail in the esp-idf-kconfig documentation once I'll find time. If you have further questions, we can definitely discuss the topic further, but probably not in this issue as we are drifting from the merit. :) |
|
Hi team, Thanks |
espressif-bot
added
Status: Done
Hi team,
can we do something with this when we are using some components from registry? It is a bit annoying or confusing and im not sure how it may impact configurations (which one is used)
Thanks
The text was updated successfully, but these errors were encountered: