Newlib overlay incorrectly packaged in lx106 overlay #42
Comments
|
Since I submitted the original crosstool issue, and I'm starting a general cleanup and refactor of esp-open-sdk, I'll take a look at this and make the changes. newlib is currently building fine for me so I'll change the overlay structure, remove the specific patch above and make sure it builds |
|
OK just finished building the toolchain with no errors. Had to rebuild the tar overlay with the correct structure and edit the patch mentioned above to remove the part that created the missing file. I checked the patch content against core-isa.h and they were identical Will do some more sanity checks but here are the files to support gcc 6.3.0 as well |
Good catch, thanks for the report.
In the newer crosstool-NG, right? That's because it no longer supports newlib-2.0.0 and tries to build a different newlib version. |
Why, we do. Although 2.5.0 is the default, 2.0.0 is still available as a valid choice (and not even marked obsolete). Rather, it is failing because we need the other parts of the local-patches that you have for newlib. |
I think it failed simply because one of the patches expected to create the file, and when you adjusted it in the overlay it was already there. I removed that specific patch and left the rest in the local patch file and it built fine. I think the bigger question is whether we can change newlib support to remove the extensive local patching and integrate the xtensa changes directly into the newlib tree like other architectures. Has this been tried previously? If it were possible, it would have to make the job of supporting new versions much simpler. |
|
As a side note - is there any kind of an official repository for these overlays? I.e., does it make sense for crosstool-NG to offer fetching them from some known location by default? |
|
Should be fixed with commit a43bb69 |
No, not yet/not that I know of. But I hope we'll get to it soon.
Maybe not from one location, but yes, fetching overlay from URL is very convenient. |
|
I have fixed the archive and have tested it with the latest crosstool and it's fine. Do you want my file? EDIT: Just realised I already attached it higher up. This included the patches as well as the overlays file |
|
I was also thinking - I have been building esp-open-sdk with the very latest crosstool-ng for a while now, and selecting the latest gcc - and it is a simple matter of renaming the clone of this repo, and then copying the samples, overlays, and local patches into the crosstool tree. Do you think it is still worth maintaining this clone of the whole crosstool tree, or should we perhaps look at bringing everything into the main crosstool repo? This repo/effort could then become the place where we could work on supporting xtensa ports of latest versions of newlib and the other tools, and in maintaining the download URLs for the overlays etc? Right now the newlib build relies on extensive patching which makes it very fragile in supporting later releases - would be awesome to have a way to more easily move to the latest lib esp-open-sdk can then pull directly from crosstool-ng for its build as well. |
I think there's not much to bring there. newlib patch needs to go upstream, ok, I'm on it. Overlays should really be fetched from external URL instead of being a part of the crosstool-NG. Samples are easy.
I'm not sure it's ready to abandon the default gcc-4.8. |
|
I've been building and using esp-open-sdk with gcc 5.2.0 and now 6.3.0 for almost a year. The later versions do a lot more with LTO that is quite useful. BTW, the force-l32 patch you sent me through the forums seems to be working fine in gcc 6.3.0 :-) and I am about to pull your latest patches and see if they apply to 6.3.0 and merge if necessary. I also see gcc 7.1.0 has just been added too, so 4.8.x is getting quite old. |
|
And you are right - merging this work completely into upstream would be really quite simple, especially if pulling overlays from a URL is added. I am happy to help out in any work to newlib if you would like. |
|
I'm interested in compiling 6.3.0/7.1.0 for esp-open-sdk - any tips on getting that to work? Seems like master is not compatible with esp-open-sdk, is there a specific commit you're using? |
|
Been a while since I've recompiled so I'm a bit rusty but I did make rough notes. I had to:
My current gcc is 6.4.0 - you'd have to make some adjustments to the patches for 7.1.0 but it's not too hard. Email me if you want a zip of the project I made containing the deltas |
An issue has been submitted in upstream crosstool-NG (crosstool-ng/crosstool-ng#698) and while looking at it, I tried to build a configuration using an overlay, xtensa_lx106.tar. It failed.
The reason for the failure is that the newlib portion of the overlay is extracted into a wrong directory. The overlay tarball is extracted using the
tar --strip-components=1 -xv -f /home/avn/work/ctng/xtensa/crosstool-ng/overlays/xtensa_lx106.tar newlibcommand. The contents of the archive is as follows:The newlib build fails because the
newlib-2.0.0/newlib/libc/sys/xtensa/include/xtensa/config/core-isa.hfile is missing. Accounting for the first stripped path component, this file should have been packaged asnewlib/newlib/libc/sys/xtensa/include/xtensa/config/core-isa.h(i.e. one level deeper in the directory tree).The build does not fail in this fork because one of the local patches (
local-patches/newlib/2.0.0/0002-xtensa-cleanups.patch) creates this missing file.The other two overlays in the
overlays/directory have the newlib packaged correctly. E.g. in esp32 overlay:With that fixed, newlib still fails though ("Newlib does not support CPU xtensa") - it looks like your local patches need to be ported upstream, to crosstool-NG and/or newlib.
The text was updated successfully, but these errors were encountered: