Seperate out the chips.gcc_toolchain in the context of idf-install.py Vs linking#283
Seperate out the chips.gcc_toolchain in the context of idf-install.py Vs linking#283gopakumarce wants to merge 1 commit intoesp-rs:masterfrom
Conversation
… Vs linking See thread esp-rs#271 and espressif/crosstool-NG#50 The toolchain name that is supplied to idf-install.py Vs what is actually used when compiling/linking can be slightly different - the installation can be given one toolchain name and underneath installs multiple things, and at compile/link time one of those installed tools is selected based on the specific idf target
|
in the light of #235 and as a mitigation possible usage of |
|
@ivmarkov any thoughts on this :-? |
I don't understand the problem still. Can you elaborate what is the problem, and what you would like to see changed? |
@ivmarkov sorry for the confusion - the context for this is #271 - its a minor thing, if I want to get the gcc that I can use to then compile a C file and produce a .o (during bindgen), I cannot use chips.gcc_toolchain() because it returns xtena-esp-elf .. xtensa-esp-elf can be supplied as the parameter to idf-install.py which is just fine, it will install the right toolchains. But when compiling, we have to give xtensa-esp32-elf or xtensa-esp32ss-elf etc.. (pls see the thread with the xtensa compiler person espressif/crosstool-NG#50 ) So all I am doing here is to basically say that the toolchain name supplied as an idf-install.py parameter is different from the exact toolchain name used for compilation, and keeping seperate APIs for that |
3 participants
See thread #271 and espressif/crosstool-NG#50
The toolchain name that is supplied to idf-install.py Vs what is actually used when compiling/linking can be slightly different - the installation can be given one toolchain name and underneath installs multiple things, and at compile/link time one of those installed tools is selected based on the specific idf target