Build fails on MacOS 10.15 Catalina

[peerst]

There are isl cause build errors when building the toolchain on MacOS 10.15 Catalina with current master, the firs one e.g.:

../../gcc-7.3.0/gcc/graphite-isl-ast-to-gimple.c:98:7: error: use of undeclared identifier 'isl_id_free' isl_id_free (it->first);

It seems to be cause by a too new isl version:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86724

[peerst]

@c-mauderer this is preventing Mac users which are on 10.15 (the latest since last fall) to build the toolchain and work on drivers. How can we fix this?

[c-mauderer]

It seems like a gcc bug that is present on older gcc versions. So I think there are two possibilities:

1. Either the necessary patch would have to be backported and applied by the rtems-source-builder.
2. Or we should think about an update to a recent rtems-source-builder / RTEMS / libbsd version. In this case I would suggest the RTEMS 5 release version. I plan to do one upgrade for GRiSP2 too so that it is based on that version.

[ThomasArts]

I have also tried to compile on Ubuntu 18.04. I get segmentation faults and other errors. Even after increasing memory to 8GB in Linux VM, it did run for an hour and then gave up.

It might be worth to consider a docker container that you test compilation for and ship that docker for build. In that way people that do not want to spend hours on getting it to work can go for the docker option.

[c-mauderer]

@ThomasArts: Also it is possible, that your problems would be solved with a new gcc too, the problem seems to be a different one. @peerst had a very specific bug with the gcc version used for this repo. I'm not sure whether a docker would work for MacOS (which was the original problematic host here).

[peerst]

Linux based Docker Containers work quite well under MacOS

[c-mauderer]

OK. Then it's three possible solutions:

1. Either the necessary patch would have to be backported and applied by the rtems-source-builder.
2. Or we should think about an update to a recent rtems-source-builder / RTEMS / libbsd version. In this case I would suggest the RTEMS 5 release version. I plan to do one upgrade for GRiSP2 too so that it is based on that version.
3. Someone can create a docker container (I never tried that), that maybe can be build via github CI/CD.

[peerst]

2. Or we should think about an update to a recent rtems-source-builder / RTEMS / libbsd version. In this case I would suggest the RTEMS 5 release version. I plan to do one upgrade for GRiSP2 too so that it is based on that version.

I say we do this. Having grisp-1 and grisp-2 toolchains on the same version is a good thing in itself. Let me know if we can do some testing

[peerst]

One more question: this opens up the possibility to build the GRiSP-2 toolchain that it can build GRiSP-1 too, doesn't it?

[c-mauderer]

One more question: this opens up the possibility to build the GRiSP-2 toolchain that it can build GRiSP-1 too, doesn't it?

It's both the same ARM toolchain. So that should work. I didn't took that into account when creating the scripts for GRiSP2. But there is nothing that would speak against building the GRiSP-1 BSP in the same environment. Basically it means extracting the configuration options and adding a build target. Its a bit more difficult for support scripts like for debugging and similar.

But note that it is a topic that currently has low priority for me because I still have some other open GRiSP-2 stuff to work on. And if needs more time I might have to discuss with Thomas whether we can work on that during the GRiSP2 project.

[peerst]

That people can't build the GRiSP-1 toolchain on any modern OS (newer MacOS don't work the same as newer Linux versions) has some urgency for us.

That we have one toolchain instead of two has no urgency at all and is at the utmost a low priority nice to have. Was only suggesting it for the case that it actually makes this easier

[c-mauderer]

I have created a branch with a update to RTEMS5. I made sure that it is compile clean but I currently don't have a hardware here to test it (I'm currently working from home and the GRiSP1 boards are in the office). So please tell me if it doesn't work. Then I'll try to get my hands on a GRiSP1 again.

I would expect that you maybe need some of the newer adaptions for Erlang that you made for GRiSP2. Ther version is nearly the same (+- a few commits). The reason that it is not exactly the same is that GRiSP2 is not yet finished and there are some working commits on the branch used by GRiSP2.

[c-mauderer]

Link to the branch: https://github.com/grisp/grisp-software/compare/cm/20200820_update_to_5

[c-mauderer]

PS: I decided against integrating it into the grisp2-rtems-toolchain. That has two reasons:

• It would be more work because the examples and escpecialy the bootloader would have to be build there too.
• It would mean that the GRiSP2 repo would be the one to go to. I think that would be a bad idea as long as there is still active development in that repo.