ESP8266 Community Forum

- Fri Apr 23, 2021 5:31 pm #91183 The tooling versions to build are in the crosstool conf files, so you will need to change them there.

Each time I revved a new version, I had to copy the patch files from the earlier versions and then manually update them so they were correctly applied to the later code base. Overall this was not a huge job as the code doesn't change much.

The jcmbkbc fork hasn't been touched in forever so I would use both that and the espressif fork as references, but I would check out the core crosstool repo itself and start from there. As usual, the Espressif guys simply hack the core code rather than making something that is future proof - at least the jcmbkbc fork isolates the patches so they can be used with later gcc versions, albeit manually.

If you would like a web call together to go through it I would be happy to do that if we can work out a common time

- Sat Apr 24, 2021 3:49 am #91187 I think the best approach is to fork (what jcmbkbc did) the original tree, then apply your own commits (not patches, real changes). When it's time for a new version, rebase (not merge/pull) your own fork to the latest head of the parent, that will keep your own changes at the top and easily managable. It may give some conflicts though that need manual resolving, but in my experience, that easier than re-apply all your own changes. I will try this approach by cloning the jcmbkbc repo and rebase it to the current state of crosstool-NG.

If that doesn't work, I will also try to locate where in crosstool-NG the gcc-version selection is made and try to hack it in myself, can't be rocket science I guess. This of course fails if there is need for lx106 specific patches, but apparently for gcc 8 and gcc 9 there are already none required (not found at least).

I am not completely sure, yet, what your approach exactly means.

- Sat Apr 24, 2021 9:28 pm #91206 crosstool uses directories and files to automatically apply patches to the core code after it downloads it, and also to set up different MCU builds - so you wouldn't fork it, because there's nothing to modify really, it's all just file additions

- Sun Apr 25, 2021 4:03 am #91209 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?