Thanks for the quick response! I'll investigate the static linking situation and try some simple examples to see what works and what doesn't for me. The situation with building modules with GCC 10 and supporting SharedCLibrary is about what I expected, but I wanted to make sure.
Regards, Jake On Mon, Aug 2, 2021 at 12:08 PM Lee Noar <lee.n...@sky.com> wrote: > > 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 _______________________________________________ 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
