i386 and epiphany on FreeBSD 13 for rtems 5

[Joel Sherrill]

On Wed, Dec 22, 2021 at 9:38 AM Karel Gardas <karel at functional.vision> wrote:
>
> On 12/22/21 3:51 PM, Joel Sherrill wrote:
> > Hi
> >
> > Both i386 and epiphany rtems 5 GCC fail to build on FreeBSD 13. It
> > appears that the newer compiler on FreeBSD 13 does not like some code
> > from the older GCC.
> >
> > Logs linked here:
> >
> > epiphany - https://lists.rtems.org/pipermail/build/2021-December/030627.html
> >
> > i386 - https://lists.rtems.org/pipermail/build/2021-December/030628.html
> >
> > I only see two fixes. (1) Add --disable-werror to these targets on
> > rtems5 or (2) update the gcc on rtems5. We always are resistant to (2)
> > so I guess that leaves us with option (1).
> >
> > Thoughts, comments, jokes, concurrence?
>
> joke? Here is one: what about to bootstrap native gcc 7.5.0 with
> --disable-werror and then use that to compile i386 cross-compiler?

The RSB does actually have native gcc bsets. But they have not been
updated to be more recent than 4.9.

If there isn't a native OS package for an older gcc, updating these
would be a good option.

> Remark: looks like you will not be able to keep tools from past working
> on modern systems indefinitely which means you can also declare rtems5
> tools support for FreeBSD 12.x max.

Yep.

> Or, what about to require installed gcc able to bootstrap cross-compiler
> without issues? My pretty current FreeBSD 14 provides following gccs:

Are these installed in a special directory where they can be ignored
for rtems 6 or 7 tool builds? Sorry to ask but we want this FreeBSD 13
VM to be easily in the preferred state for 5, 6, and 7 test sweeps.

For rtems 6 and 7, using clang would be preferred.

>  $ pkg search gcc|grep "GNU Compiler Collection"|grep -v "Cross"
> aarch64-none-elf-gcc-8.4.0_3   GNU Compiler Collection for bare metal
> aarch64 cross-development
> arm-none-eabi-gcc-8.4.0_3      GNU Compiler Collection for bare metal
> arm cross-development
> arm-none-eabi-gcc492-4.9.2_5   GNU Compiler Collection for bare metal
> arm cross-development
> gcc-10_4                       Meta-port for the default version of the
> GNU Compiler Collection
> gcc10-10.3.0                   GNU Compiler Collection 10
> gcc10-devel-10.3.1.s20211008   GNU Compiler Collection 10
> gcc11-11.2.0                   GNU Compiler Collection 11
> gcc11-devel-11.2.1.s20211009   GNU Compiler Collection 11
> gcc12-devel-12.0.0.s20211128   GNU Compiler Collection 12
> gcc48-4.8.5_14                 GNU Compiler Collection 4.8
> gcc8-8.5.0_1                   GNU Compiler Collection 8

One of these last two should be the best choices. gcc 8 or 48
if that doesn't work.

> gcc9-9.4.0                     GNU Compiler Collection 9
> gcc9-devel-9.4.1.s20211007     GNU Compiler Collection 9
> riscv32-unknown-elf-gcc-8.4.0_3 GNU Compiler Collection for bare metal
> riscv32 cross-development
> riscv64-none-elf-gcc-8.4.0_3   GNU Compiler Collection for bare metal
> riscv64 cross-development
>
>
> I guess this is more than enough to throw away system wide clang and use
> one of those?

Except for using the same VM with different options/paths to build rtems
5, 6, and 7 in the preferred way. Help on that is appreciated.

--joel

> Karel