[gccsdk] Some feedback on using GCC 10.2.0

I've just started getting into RISC OS as a hobby project to do
something with my Raspberry Pi 3, GCC toolchain, and POSIX knowledge.
I managed to get the GCC 4.7.4 SDK running on my Ubuntu PC, and then
GCC 10.2.0 and binutils 2.30 as well. So far I've been extremely happy
and impressed with the quality of the autobuilder and toolchain. I'd
feared that UnixLib wouldn't be as capable as it is, and I'm happy to
see familiar GNU EABI and ELF formats.

I've been making a few improvements to the ports and toolchains in my
own git repo mirrored from Subversion and hosted on GitHub. Feel free
to integrate any of my changes into the main repo. In fact, I'd prefer
for any interested users to merge changes from my repo without asking
me for permission for each one.

https://github.com/jhamby/riscos-gccsdk

You probably don't want to take the patch I made to change the default
GCC 10 CPU/FPU target from ARMv7-A and VFPv3 to Cortex-A53 and Neon,
but I've tried to make everything else reasonably generic. Now, on to
a few areas of difficulty that I'd like to solicit some opinions on
how to fix.

First, I had a bizarre time with Qt 5.5.0 failing to load
libqriscos.so, which I finally tracked down to SOMLoader failing to
link in libbz2.so.1.0, by way of libfontconfig.so.1.8.0 and
libfreetype.so.6.

As a workaround, I've patched my setvars for libbz2-1.0 to only build
a static library, with "-fPIC" so it can be linked into other shared
libraries, and that worked around the issue well enough for me to run
AnalogClock and find another runtime failure with FontConfig itself if
I try to run any Qt programs that draw text.

I'm confused why this is happening, and unlike with missing shared
libs, there wasn't any output as to what went wrong. dlopen() just
returned NULL to libQt with a "filename not found" error. I had to set
DEBUG_PRINT to 1 in gcc4/riscos/soloader/module2/som_elf.c and build a
new SOMLoader to discover that it was libbz2.so.1.0 where the dlopen()
failed and returned NULL.

There's another SOMLoader issue I'm curious about, which is the patch
to binutils in autobuilder/develop/gcc/bfd.elf.c.pp that comments out
the section that merges a data segment into a previous text segment,
because the comment says RISC OS requires two segments. That patch
failed to apply cleanly when I attempted to upgrade to binutils 2.31,
so I left it out, and SOMLoader indeed complains that the data segment
is missing. I'm curious if it would make sense to patch SOMLoader to
not fail here. Is there a reason for the requirement for a separate
data segment?

One high-priority item for me is that I'd like to build the
system/khronos package for OpenGL ES 2.0 on my Pi using GCC 10, and I
did get it to work when built with GCC 4.7.4, but unfortunately, even
after modifying to use "arm-riscos-gnueabihf-" tools instead of
"arm-unknown-riscos-" (including adding a "-gnueabihf" option to
cmunge to tell it to do the same), I'm getting these failures linking
the RISC OS module with GCC 10 tools:

khronos.o: In function `__module_header':
(.riscos.module.header+0x0): multiple definition of `_start'
/home/jhamby/Projects/RISCOS/GitHub/riscos-gccsdk/env/lib/gcc/arm-riscos-gnueabihf/10.2.0/../../../../arm-riscos-gnueabihf/lib/crt0.o:/home/jhamby/Projects/RISCOS/GitHub/riscos-gccsdk/build/gcc/gcc-10.2.0/cross-build/arm-riscos-gnueabihf/libunixlib/crt0.S:16:
first defined here

/home/jhamby/Projects/RISCOS/GitHub/riscos-gccsdk/env/lib/gcc/arm-riscos-gnueabihf/10.2.0/../../../../arm-riscos-gnueabihf/bin/ld:
Unable to find Image$$RO$$Base

/home/jhamby/Projects/RISCOS/GitHub/riscos-gccsdk/env/lib/gcc/arm-riscos-gnueabihf/10.2.0/../../../../arm-riscos-gnueabihf/bin/ld:
Unable to find Image$$RW$$Base

khronos.o: In function `_CMUNGE_ce':
(.riscos.module.header+0x1a0): undefined reference to `_Lib$Reloc$Off$DP'
(.riscos.module.header+0x1ac): undefined reference to `_Lib$Reloc$Off$DP'
khronos.o: In function `_CMUNGE_init':
(.riscos.module.header+0x1e4): undefined reference to `_clib_initialisemodule'
(.riscos.module.header+0x1f0): undefined reference to `_Lib$Reloc$Off$DP'
(.riscos.module.header+0x204): undefined reference to `_Lib$Reloc$Off$DP'
(.riscos.module.header+0x22c): undefined reference to `_clib_finalisemodule'
khronos.o: In function `_CMUNGE_init_10':
(.riscos.module.header+0x234): undefined reference to `_Lib$Reloc$Off$DP'
khronos.o: In function `_CMUNGE_fin':
(.riscos.module.header+0x268): undefined reference to `_Lib$Reloc$Off$DP'
(.riscos.module.header+0x288): undefined reference to `_clib_finalisemodule'
khronos.o: In function `_CMUNGE_final_10':
(.riscos.module.header+0x290): undefined reference to `_Lib$Reloc$Off$DP'
khronos.o: In function `_CMUNGE_swi_handler':
(.riscos.module.header+0x2d0): undefined reference to `_Lib$Reloc$Off$DP'
(.riscos.module.header+0x2dc): undefined reference to `_Lib$Reloc$Off$DP'
/home/jhamby/Projects/RISCOS/GitHub/riscos-gccsdk/env/lib/gcc/arm-riscos-gnueabihf/10.2.0/../../../../arm-riscos-gnueabihf/lib/crt0.o:
In function `crt1_data':
crt0.S:(.data+0x14): undefined reference to `main'
collect2: error: ld returned 1 exit status

Can anyone shed some light on the way that this is supposed to work
(and does work with GCC 4)? Thanks in advance.

One final toolchain item that I noticed is "elf2aif" doesn't work yet
for converting statically-linked gnueabihf binaries to AIF. It
immediately fails due to the OS ABI changing from ARM to generic in
the ELF file header, but if I override that check, the resulting
binaries immediately crash with an EMT trap. Is there some special
startup code that needs to be executed that the AIF header isn't
calling, perhaps for C++?

Best regards,
Jake Hamby

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK