Forum > Embedded
Problem linking for Xtensa (ESP32)
electronickiwi:
No change using the -Xe option and leaving out the -O3 option.
It still says "Can't call the linker, switching to external linker"
I'm assuming I only need to put -Xe and not include the path to the linker (as that is specified in -FD option)?
TRon:
--- Quote from: electronickiwi on May 09, 2020, 11:45:08 am ---No change using the -Xe option and leaving out the -O3 option.
--- End quote ---
Ok, thank for trying and reporting back.
I noticed that you posted pretty quick after my post, and the script more or less already explained that the issue is not related to optimising.
--- Quote ---It still says "Can't call the linker, switching to external linker"
--- End quote ---
Sorry to hear that. I have to surrender here. Hopefully one of the more experienced developers or the maintainer of this particular target reads this and is able to help you out here.
Perhaps worth a report in the mantis bug-tracker to draw some more attention to it ?
--- Quote ---I'm assuming I only need to put -Xe and not include the path to the linker (as that is specified in -FD option)?
--- End quote ---
That is correct.
You can try though. FPC will respectfully throw that back in your face with an error :D
electronickiwi:
Thanks TRon.
TRon:
--- Quote from: ccrause on May 09, 2020, 09:24:42 am ---EDIT: As others pointed out this is incorrect!
--- End quote ---
Nevertheless, your input is very much appreciated.
You are most probably correct in that i should not have named it literally "to add the path to your binutils", which perhaps suggested that the -FD option is meant only for pointing to binutils.
You are able to 'abuse' that option to add about every path that has at least some meaning for the toolchain, so that FPC is able to actually set things in such motion that an executable (or other kind of output) is constructed.
As pointed out by others (thank you others), binutils is a chain of tools (hence toolchain) that is/becomes part of the compiler utilities (although originating from external sources).
For most generic targets ld, as and others like strip are pretty common, but there are some pretty unorthodox targets out there (that are supported by FPC as well) and which require FPC to (indirectly) invoke a complete set of (exotic) tools in order to produce something useful.
--- Quote ---...
--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ----XPC:\Users\Wes\.espressif\tools\xtensa-esp32-elf\esp-2020r1-8.2.0\xtensa-esp32-elf/bin/xtensa-esp32-elf-EDIT: probably qualifies for the WoMM certification :-[.
--- End quote ---
... and that is perhaps one of such toolchains that installs itself (automatically) in such WoMM manner ;)
Another example is for instance Android with it's .apk files (which is very convenient when the toolchain is able to produce that automatically for you).
On top of that, such (wonderful) options allows for a complete standalone (independent from OS) setup for FPC. You can just toss every native + cross compiler versions onto a (big) flash-drive and you never have to worry about installing things again (that is until the next release from FPC/Lazarus team of course .. those blimey releases :D ).
marcov:
.py's don't execute on Windows without being prefixed by the interpreter ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page