ESP8266 Community Forum

It's not that I want to be wiseguy, it's not that I don't understand what you're doing.

I managed to get quite far with my approach, but now I am stuck on the final gcc not being able to build because it needs zstd for LTO and apparently ctng doesn't have it, or the wrong version (missing symbols when linking). I already turned off every LTO option I could find, but the final gcc still insists on being built with LTO, I can't find anything to turn it off.

eriksl wrote:Is it all in the overlay tarball? Or just a part?

BTW I now did the fork of the phillipov fork and a rebase to the current state of the original crosstool-ng repo, which went surprisingly well. A few commit had conflicts, primarily because the files they operate on files that are no longer present or have different content. I resolved the conflicts as good as I was able to, two commits were functionally empty now and I removed them.

First test build for some reason selected the wrong arch (alpha instead of xtensa) but otherwise almost completely built to completion (broke at binutils as the selected arch doesn't exist (alpha4ve-lx106..). It looks like I've fixed that issue now, going on again now. If this is going to work, I think it's a great base to keep our fork current with upstream and also, it's fairly easy for the upstream guys (if they want to), to merge "our" patches, which would be ideal of course.

What puzzles me is that crosstool-NG seems to have xtensa support natively, but apparently not lx106?

There are three parts to the crosstool custom build - there is the overlays, the sample config and the local patches for any tools. And you're correct - there's a generic xtensa overlay that's been developed but there's none specific to Espressif's lx-106 so they need to be copied into the tree in the right place before you build.

The sample config files are used to provide default values when you initially select the architecture, but you would override them to select the later gcc and utils.

The local patches are for architecture specific issues in things like gcc and newlib and need to be matched to the version - this is the stuff that I revved for later versions and adjusted

eriksl wrote:It's not that I want to be wiseguy, it's not that I don't understand what you're doing.

I managed to get quite far with my approach, but now I am stuck on the final gcc not being able to build because it needs zstd for LTO and apparently ctng doesn't have it, or the wrong version (missing symbols when linking). I already turned off every LTO option I could find, but the final gcc still insists on being built with LTO, I can't find anything to turn it off.

I have LTO turned on in my gcc, and it works well, but yes it's also in the crosstool build and I remember having problems with it during my own build

Something appears to be wrong in the "sample" (the default config) for xtensa, beause it selects alpha arch (or none and alpha is default, I don't know). I already did patching of the config file because I need several specific options (like a newlib that works with floats), that patching has now grown consideraly to change the arch to xtensa-lx106 and all related options. So there must be something wrong with the "sample" I guess, probably happened during the rebasing.

Can you give a hint how you got gcc10 working? It seems it's missing the zstd lib or looking in the wrong place. Building completely without LTO apparently is not possible.