Building PlingSystem

I’ve been having a go at building PlingSystem, so that I can try out some of the modules under Arcem to make sure they work properly. Apart from a couple of issues that I’ve now fixed, I’ve found a more serious one that’ll need some input: On a 32bit build host, socklib will fail to build because it creates and runs a C application (mkveneers) as part of the build process. Although the makefile for mkveneers is correctly using the HostTools makefile, the problem seems to be that it’s linking against the localy built 26bit version of the SCL stubs.

I’m thinking the correct course of action would be to get RISC_OSLib to export a second set of stubs which the HostTools makefile can then get programs to link against. Or, since mkveneers is pretty trivial, it could be rewritten in Perl.

Any thoughts?

I’m tempted to go with the second option, even though it won’t solve the general issue with host tools linking against stubs designed for the target. If we can get rid of all the tools which get built during the build process then we won’t have to worry about problems like this cropping up from time to time.

the problem seems to be that it’s linking against the localy built 26bit version of the SCL stubs.

How about storing a binary of 32 bit stubs somewhere and changing the HostTools makefile to refer to ${CLIB32} instead of ${CLIB}? Doesn’t ColourPicker do some tools at compile time too – how does it work? But yes, rewriting in some scripting language like perl or BASIC would make sense. I did the PlingSystem development on a StrongARM Risc PC so guess I never noticed.

I’ve been having a go at building PlingSystem, so that I can try out some of the modules under Arcem to make sure they work properly.

If it helps, I checked all the modules in <310> loaded on an (emulated) RISC OS 3.10, checked their *HELP printed out and checked that TaskWindow opened a task window when requested and that I could draw bezier curves in !Draw (hence floating point emulator must have been vaguely working) and that I could *RENDER a draw file. I’m using the modules in <400> on a daily basis.

How about storing a binary of 32 bit stubs somewhere and changing the HostTools makefile to refer to ${CLIB32} instead of ${CLIB}?

I guess that would make sense. It should be pretty easy to update the BuildHost product to export some suitable stubs/libs and headers which can then be checked into the Export folder in CVS. Since a suitable version of the stubs/libs are already built by HostTools it should just be a case of amending the makefile to copy them to the right place during the install phase; much easier than modifying it to build twice with two different compiler settings.

Doesn’t ColourPicker do some tools at compile time too – how does it work?

I’ve had a quick skim through the makefile and can’t see anything obvious. Were you thinking of ColourTrans? That was a slightly different issue to this one, since ColourTrans is pure assembler.

I did the PlingSystem development on a StrongARM Risc PC so guess I never noticed.

I probably wouldn’t have noticed myself, if I hadn’t previously killed Aemulor to allow the OMAP3Live image to link.

If it helps, I checked all the modules in <310> loaded on an (emulated) RISC OS 3.10, …

I’m mainly interested in CLib and FPEmulator; CLib for the previously mentioned issues I’ve had with the latest releases, and FPEmulator to see if it works properly on ARM2 machines (It looks like some FPEmulator versions break the undefined instruction handler; code which attempts to detect ARM3 by registering an undefined instruction handler and executing an MRC/MCR op will crash instead of having their handler called. It might be that I’m mistakenly trying to use a RiscPC-only version of the module, but if that was the case I would have expected more things to be broken)

draw bezier curves in !Draw (hence floating point emulator must have been vaguely working)

I thought draw didn’t make use of hardware floating point? The sources contain a copy of the 5-byte FP code from BASIC.

Doesn’t ColourPicker do some tools at compile time too – how does it work?

Were you thinking of ColourTrans?

Um, yeah, must have been confused.

I’m mainly interested in CLib and FPEmulator […] I thought draw didn’t make use of hardware floating point?

Plenty of floats and doubles in the source code. You thinking of FontManager? Anyway, I didn’t do anything with the CLib since it works on my Risc PC (26 bit) and doesn’t have any *commands.

I’m mainly interested in CLib and FPEmulator […] I thought draw didn’t make use of hardware floating point?

Plenty of floats and doubles in the source code. You thinking of FontManager?

I guess so – FontManager contains the BASIC FP code, while Draw uses its own fixed-point code (and no floating point). The only Draw-related thing that seems to use hardware FP is the !Draw app.

Also, having repeated the PlingSystem build a few days ago, but this time with Aemulor loaded, it looks like AMU is detecting that mkveneers isn’t 32bit compatible and is stopping it from being loaded. Maybe tonight I should have a go at setting up that HostTools build of clib.

No clib fix yet, but I have just checked in a Perl version of mkveneers, so PlingSystem should now build OK on 32bit hosts.