On 01/08/2021 22:23, Jake Hamby wrote:
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,
I tried to choose a default that would work on the most hardware, choosing a particular CPU seemed too specific, so I went with an architecture that seemed fairly popular. Having both VFPv3 and Neon would be the ideal I think.
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.
Does freetype have a DT_NEEDED entry (readelf -d) for libbz2? If so, does the DT_NEEDED name match the symlink for it?
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.
Something like syslog would be useful here, the dynamic linker can't use Unixlib, so any errors don't go to stderr which we may actually see.
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?
Yes, that's for shared libraries. SOManager needs to be able to find the data segment so that it can make a copy of it. When a new client starts and is linked to a particular library, SOManager will initialise the client's version of that library data from the unused copy.
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:
[snip]
Can anyone shed some light on the way that this is supposed to work (and does work with GCC 4)? Thanks in advance.
Unfortunately, GCC 10 does not support module generation as yet which is why GCC 4 is still our main compiler. The problem is that libscl which is the interface to the SharedCLibrary and what modules are linked against needs to be built as hard-float+FPA, however, FPA code generation was removed from GCC some years ago and is no longer supported. Really, what we need is a SharedCLibrary that supports VFP. Obviously, being able to build C modules is important to RISC OS and until GCC 10 can do that, we can't really have it as our main compiler. As far as Khronos is concerned, the trick is to build the module with GCC4 and the rest with GCC10. I've got some patches here to do that. I'll make sure it still builds and commit them in the next couple of days.
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,
Yes, admittedly I did know about that, but hadn't got around to sorting it out, I'll have to have a look at what I did.
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++?
I would've thought that a static program would include all the necessary start up code, is it possible that some PIC slipped through? Lee. _______________________________________________ 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
