Weird Make errors building ROM/Disc

So there are two different build failures keeping me from making builds (BCM2835 ROM or Disc, doesn’t matter) from the latest sources, and I think I must be either missing something in my system config that’s confusing Make, or there’s a bug in Make or amu, and I don’t know why the build tree I have from a couple years ago seems to work.

I made a fresh Raspberry Pi image with the 5.28 release, copied and installed DDE 3.0b from the NutPi zip, and got the same errors, including after installing the daily kernel and disc image on top of the fresh release.

The two bugs are the “sed” command in Sources.Video.Render.Fonts.ROMFonts that copies from Fonts.Encodings.UTF8Full to Fonts.Encodings.UTF8 stripping comment lines (or is supposed to) is hanging waiting for standard input on:

sed -e 's/\x23.*$//'  > Fonts.Encodings.UTF8

The build rule should work, but $< isn’t expanding to anything. If I manually replace the $< in the build rule with the name of the source file, ${UTF8ENC}Full, then I can get past this strange bug. I see that $< is used in various other Makefiles and I don’t see any odd characters in the file or anything other than the sed expression itself, that might be confusing Make.

Comparing with the Makefile from the older build that works for me, I see the rule to make ${UTF8ENC} from ${UTF8ENC}Full is new and simply wasn’t there before. My hypothesis is that Make gets confused because the path level is nested so deeply from the root of the source tree? I don’t know. It’s very strange.

What’s insidious about this bug is if I press Break then there’s be an empty target file where there should be a processed one, and a subsequent build will appear to succeed but won’t get the UTF-8 data that it’s supposed to. My guess is there’s something in the regex that’s passed to sed with “-e” that’s breaking the “$<” expansion?

The other issue is the TCP/IP code can’t find the header files that it’s supposed to be exporting from Sources.Lib.TCPIPLibs.socklib.hdr. I get a bunch of:

Error: File "InetSWIs.hdr" could not be opened

This is with ARM AOF macro assembler 4.11 [21 Apr 2021], Amu 5.34 [30 Oct 2020] and Make 1.29 [10-Oct-17] (according to the GUI info pane), all from the NutPi DDE 3.0b archive. I’m guessing the assembler is supposed to look for “InetSWIs.hdr” in one of the included directories:

objasm -depend !Depend -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"RPi\"" -pd "UserIF SETS \"Raspberry\"" -o o.sendtosm sn.sendtosm

Are there known bugs in the build with this version of the DDE? I’m at a loss as to what else it could be otherwise. I notice that the older build has a copy of the missing (from my failed build) InetSWIs.hdr copied into <Hdr$Dir>.Interface2 but how is the rule supposed to work when it’s in a directory named hdr that’s one level up from the include path? If I try to manually copy InetSWIs.hdr where it is in the other build, that doesn’t help.

Thanks in advance!

There’s one bug in the current code base that I’ve patched locally to see if it makes any difference in a full build, because now I’m getting stuck with not finding BCM2835.hdr later in the build.

The bug is the definitions of sysctlbyname and sysctl in Lib.TCPIPLibs.headers.sys.h.sysctl, Lib.TCPIPLibs.inetlib.c.sysctlbyna, and Lib.TCPIPLibs.inetlib.h.inetlib should all have void * and not const void * for the newp parameter (4th param of sysctl and 5th param of sysctlbyname).

Having removed the const from the prototypes in the two .h files and the .c file, I’m curious if that will get me any further with a clean build, which I’m attempting now.

The sources do, or did as it turns out, build with DDE31b.

RISC OS source and the DDE are all part of the same ROOL git repository. Changes to RISC OS components may also involve changes to DDE tools and libraries.

The difference between RISC OS source and DDE is that the DDE is not free.

ROOL may be offering a free Pi only DDE

A test Disc build with DDE31b has completed here, Pi RPMs were successfully built a week ago.

Just to be awkward a Pi ROM build from today’s source code tarball has just failed with an error in Sound1. There was an overnight update to that I will report on that fully later.

And I have just noticed DDE31c is now a thing.

The two bugs are the “sed” command […] hanging waiting for standard input on

Most likely you have an old Sed (or there’s a conflicting Sed somewhere else on your Run$Path). This one was updated in May 2020 to solve a hang, as I recall.

Having removed the const from the prototypes in the two .h files and the .c file

Are you sure you’ve checked out the latest copy, and not just the copy at the time the products files were last updated? Carefully check your Git runes for they are non obvious. A quick sanity check is to look in the VersionNum file – TCPIPLibs are 5.76 here.

Just to be awkward a Pi ROM build from today’s source code tarball has just failed with an error in Sound1

Mea culpa. The ROM build roulette stopped on IOMD, and that built fine, as did a RAM loading standalone module. Turns out macros and stuff mean an ADR is out of range on Pi and others.

I think this must be related to the version of Make in DDE 3.0b. It doesn’t seem to be sed because sed is being called with the wrong command-line, according to the output from Make.

By the same logic, I think the missing InetSWIs.hdr must be because of some other issue with the build rules? It’s either that or a bug in ObjAsm, I suppose. I tried to build with a fresh install of the US and even changed my Keyboard from USA back to UK just in case it was locale-related. No luck.

One potential clue is that the “Prepare” Obey script in the sources that I download from GitLab can’t find the Acorn C/C++ compiler and tools because they’re looking for <SetPaths32$Dir> only, while the same script from the source archive from the same day complains only if "<SetPaths$Dir>" = "" AND "<SetPaths32$Dir>" = "". So if I try to build from an archive of the Git sources that I made myself, I can’t even get the prepare script to run because it says WARNING: It doesn't look like the filer has 'seen' your C/C++ installation yet.

Needless to say, my version of DDE is setting SetPaths$DIR but not SetPaths32$Dir.

DDE 3.0b

I hope you mean 30b because 3.0 would be circa-1990 :)

even changed my Keyboard from USA back to UK just in case it was locale-related.

Definitely not; I’ve always had my keyboard set to USA and have never had the issues you’re encountering.

LOL, yes, DDE 30b makes much more sense!

Honestly, I always felt like I got a buggy version of the DDE with 30b, mostly because I saw similar issues to the ones I’m presently seeing attempting to do ROM builds in the past, and never figured out why they went away the first time I saw them, but also when I double-click !ObjAsm, instead of opening an app icon like the other apps in the DDE folder, and like the manual describes, I get an error window saying:

Application name in description file inconsistent with star command
Press SPACE or click mouse to continue

However, I can run objasm from a Task window. If I do have to pay for a license to an upgraded DDE without the mysterious build script failures, I will, especially if it’s only the upgrade price. I’ll give ROOL my Nut Pi serial number in case that helps. I understood when I was buying it that the Nut Pi version of the DDE didn’t include the Linux tools, and the website doesn’t appear to promise that it came with the one year of free DDE upgrades like the full version (so I assumed that it didn’t).

Nut-Pi. My understanding at the time of my purchase is the cost is split across the numerous applications, and you’ll need to buy a developer license, and then you will get free upgrades for a year.

Yes, a think NutPi was very much a bargain-basement way in, but no further.

I remember having to apply a couple of hacks with my version of the DDE (I got a free upgrade to DDE 27, so I presume I bought DDE 26?). It’s worth searching this forum, as I’m sure I recall threads about SetPaths and sed. Perhaps a couple of obey files just need a tweak?

If you just want to experiment with LanManFS, I wouldn’t worry about building an entire ROM. I did follow the build guide on the ROOL wiki, but then just opened the component I wanted (funnily enough LanManFS) and ran !MkRam. No need to build a whole ROM – that implies some proper low-level trickery, which I don’t feel qualified to perform!

I remember following this: https://www.riscosopen.org/wiki/documentation/show/How%20to%20build%20RISC%20OS

@ Jake

Out of curiosity, did you install !CoreUtils via !PackMan (or other ways)? If so, could you remove it from the !Configure → Boot → Look At (if it’s in there) or avoid opening the directory that contains it (which should be $.Apps.Utilities) before you try to build RISC OS ?

!CoreUtils is known to create macros that interfere with few RISC OS commands and utilities like link (which is also a filename in common with DDE’s link).

When cleaned up, reboot and retry following the instructions Richard has shared above.

Just my 0.5c