Re: [gccsdk] Some feedback on using GCC 10.2.0

In article
<CABfdNnTthprvLa+F7O-+pzLv_e84_mEUi2c0vYugvzC3APuhgg@mail.gmail.com>,
Jake Hamby <jake.hamby@gmail.com> wrote:
> 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.

I've merged your changes for libgpg-error0 and libwebp6 so far. Should be
able to most of the rest.

Most of the ports available in PackMan are built statically. There seems to
be issues when using shared linking and calling another program. e.g. bash
calling another program exits after the command. Using static linking it
works fine.

> 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.

Using your patches for 10.3.0 both the native and GCCSDK build working OK
so far.

Building with --with-fpu=neon-fp-armv8 and --with-cpu=cortex-a72 gets a
good speed up runing generated programs on a Pi4.

> 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.

I couldn't reproduce this. Both Qt 5.5.0 and 5.5.1 worked OK. I'm wondering
if it's to do with the order things are built.
If you're looking at improving the Qt port. Adding native keyboard handling
will make RPCEmu a lot more useful. Also adding an audio backend to get
sound working.

Anything using the current port of Qt5 has lots of patches to use the old
Signals and Slots. Not sure why the 'new' way doesn't work.
I also noticed you'd got Qt 5.6.3 running later versions of Otter browser
need at least Qt 5.6.

There are also two new ports using Qt5. FractGen and GPXSee.
These highlight a problem with 180dpi screen modes (EX0, EY0). The screen
doesn't get scaled when using these modes.


_______________________________________________
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