Building HardDisc4

I have an up to date installation of DDE30, including February’s 30d update. (Unless I’ve broken something, that is.) I downloaded the nightly sources for HardDisc4 and tried to build them.

The first problem is that !Prepare thinks my DDE hasn’t been seen because SetPaths32$Dir doesn’t exist. I don’t understand this, as the requirement isn’t new. So I added a line to Boot to set SetPaths32$Dir <SetPaths$Dir>

When build eventually runs, all the Perl invocations appear to exit with Return code too large.

Then there are hundreds, if not thousands, of errors, serious errors and fatal errors. A common theme is that included or GET files couldn’t be opened.

What basic thing have I done wrong or failed to do?

I’ve built HardDisc4 before, with earlier sources, and built AcornSSL many times.

Yes, there’s an issue with SetPaths.

Do you have an older DDE you can temporarily install to see if that works?

Just a thought – are you running Builder with the correct (DiscDev?) option set up? Do you have the OS sources for the primary header files? In other words – what is the error saying cannot be GETted into the code, and does that file actually exist anywhere?

The first problem is that !Prepare thinks my DDE hasn’t been seen because SetPaths32$Dir doesn’t exist.

It looks like DDE29 and earlier used SetPaths32, but in DDE30 it was changed to just SetPaths. I never spotted this issue, because 90% of the time I use a script which automates a lot of the setup (including setting SetPaths32$Dir to my main DDE install). I guess all the other developers must be doing the same, for you to be the first person to report it!

(pre-post edit: I see that Rick’s posted to say that other people have reported this issue, and the linked thread indicates the warning from Prepare can be ignored because the InstallTools script which does the actual work has been updated to cope with the new variable name) (actual edit: yes, the warning from !Prepare can be ignored – there’s no need to manually set SetPaths32$Dir)

When build eventually runs, all the Perl invocations appear to exit with Return code too large.

I’m not seeing that problem – do you have another install of Perl somewhere, e.g. from Packman / riscos.info? I can’t remember which tool was causing the problems, but I’m fairly certain that there have been other issues reported in the past where if you have non-ROOL versions of certain tools installed then they can cause builds to break. riscos.info’s ports are particularly good at doing this, because they generally work by setting up aliases, causing them to take priority over whatever’s in your Run$Path (which is where the ROOL tools will end up). Although with ROOL’s Perl it looks like it’s placed right at the end of Run$Path, so a Perl placed in !Boot.Library would also take priority over ROOL’s one.

There were also historic problems with the DDE conflicting with the build system (you had to make sure the DDE hadn’t been seen before running !Builder and doing a build), but I think those might have been fixed now. (This is one of the reasons I use a script to run Prepare, since it can just set SetPaths32$Dir and avoid all the other stuff that the DDE does which was causing the breakages)

Then there are hundreds, if not thousands, of errors, serious errors and fatal errors. A common theme is that included or GET files couldn’t be opened.

That’ll be caused by the Perl failures, since Perl is used to process many of the header files during the “export headers” phase.

What basic thing have I done wrong or failed to do?

My test today was:

1. Fresh boot to get rid of any lingering stuff I was working on earlier
2. Let the machine see !SetPaths
3. *set SetPaths32$Dir <SetPaths$Dir>
4. Extract sources using UnTarBz2
5. Let it run Prepare and Builder
6. Register the build tree (since I extracted somewhere new)
7. In the Build Options window, made sure I re-selected the build directory (IIRC it does some setup when you make a selection there, which might be skipped if you just leave it at the default value if you’ve just registered a build tree) edit: nope, further testing suggests that this isn’t needed
8. Select the ROOL.Disc environment
9. Do a build with Export headers, Export libraries, Install disc

That successfully produced a build, so unless you’ve done anything significantly different I’d guess that your problem is with a second copy of Perl installed somewhere which is taking priority over the ROOL one.

there’s an issue with SetPaths

I think I’d already fixed that.

Do you have an older DDE you can temporarily install to see if that works?

I suppose I can use my DRest application to recover the previous version from the last backup.

are you running Builder with the correct (DiscDev?) option set up?

Yes.

Do you have the OS sources for the primary header files? In other words – what is the error saying cannot be GETted into the code, and does that file actually exist anywhere?

What I have is the nightly sources (yesterday I was using 220313; today there’s a new version 220318; the results appear to be the same), on which I have used UnTarBZ2 1.11 and then untarred them. So I have to assume they’re complete. I only looked for one missing file, and there appeared to be 4 items with that leafname, but whether any of them is the right one I don’t know.

The version of the sources that I was successfully working on, which is probably 2022-12-28, has a directory RiscOS.Export.APCS-32.C which has 4 subdirectories, Global, h, Interface and o, all of which are populated. The versions from 2022-03-13 and 2022-03-18 don’t have that C directory. I’m not clear on whether it should exist in the tarball or be copied in from somewhere else – but, if somewhere else, then where?

Try *show setpath* to ensure the correct DDE has been found, noting the potential confusion with the two possibles, SetPaths$Dir and SetPaths32$Dir as already mentioned.

DiscDev builds properly here with DDE30d.

do you have another install of Perl somewhere, e.g. from Packman / riscos.info?

Not AFAIK. Perl isn’t something I use at all, except inherently and automatically (i.e. without any deliberate intervention on my part) in building RISC OS sources. And my Downloads directory for RISCOSinfo doesn’t even contain a Perl archive. And, without running any of the build stuff, there are no system veriables matching perl*.

SetPaths$Dir and SetPaths32$Dir are identical: SCSI::HardDisc4.$.AcornC/C++.!SetPaths

Running the build, all the Perl* system variables begin with SCSI::HardDisc4.$.HD4Dev.RiscOS.Apps.!Perl which is indeed within the build directory.

Just a thought, is there an alias set for perl pointing to an old/broken version. That gotcha is ringing a bit of a bell.

P.S. Oops. A bit of post crossing going on.

Just a thought, is there an alias set for perl pointing to an old/broken version.

No. The only alias that includes “perl” is Alias$@RunType_102, which points to !Perl in the current build directory.

The only other copies of Perl I have are in other build directories, but none of the system variables points to any other than the one in my current build directory.

A bit of post crossing going on.

Yes; I am grateful for all the help I’m getting, which is very much in real time!

One thing to try which might help narrow down the problem is to select the build directory & environment, and then manually run an export script (e.g. Sources.Kernel.MkExport) to see if it fails. If it doesn’t do anything (i.e. just says “Kernel: export complete”), just use the filer to Stamp the entire Kernel folder to refresh the timestamps, and then run it again.

If that fails, you can also try opening a task window and running one of the perl commands manually.

Also these last two aren’t going to help you, but after doing a bit more testing I can report that:

1. You can ignore the warning from Prepare about SetPaths32$Dir not being set
2. My habit of re-selecting the build directory after newly registering it doesn’t seem to be needed

Basically it comes down to the Export.APCS-32.C directory not existing, as I said above. Where does this come from? Should it be a part of the source tarball?

Do I need to have built the kernel previously?

After extracting the tar file, Export.APCS-32 only contains a Hdr folder. Prepare/InstallTools adds a Lib folder (containing c++lib). The C folder is created at the start of the “Export headers” build phase by HdrSrc’s makefile (Programmer.HdrSrc.Makefile); this is what the command should look like in the build output:

do mkdir -p <CExport$Dir>.h

CExport$Dir should be <blahblahblah>.Export.APCS-32.C. CExport$Dir should be set by Env.!Common, when you select the Disc environment in Builder.

So it’s possibly a rogue mkdir conflicting with ROOL’s one, or CExport$Dir being set wrong.

Do I need to have built the kernel previously?

No. The kernel code only gets built for ROMs. For the disc it’s only used for header exports.

Basically it comes down to the Export.APCS-32.C directory not existing, as I said above. Where does this come from? Should it be a part of the source tarball?

The source tarball only contains APCS-32.Hdr. APCS-32 is populated in the Export headers and Export libraries Builder phases.

Attempting to run Sources.Kernel.MkExport:

FAppend <cexport$dir>.Global.h.VIDCList h.VIDCList Global.h.VIDCList
AMU: * Can’t open ‘SCSI::HardDisc4.$.HD4Dev.RiscOS.Export.APCS-32.C.Global.h.VIDCList’ *

AMU: * ‘export’ not re-made because of errors *

(If I’ve mistyped anything in there, I apologise – I’m typing on a Linux box, not copy-pasting)

Continuing the struggle…

I’ve downloaded today’s tarball and extracted it, using a fresh download of UnTarBz2. I’ve run !Prepare, which was successful. I’ve attempted a build, with the environment set to ROOL.Disc, and with Export headers, Export libraries and Install disc ticked. The first error was “cannot create directory ‘SCSI::HardDisc4.$.Downloads.ROOL.HD4Dev.220319.Disc.RiscOS.Sources.Export.APCS-32.C.h’: No such file or directory”

The C directory does not exist. It has not been created. I don’t know if mkdir can create multiple directory levels at a time. CExport$Dir is the above path except for the trailing h.

OK, I created the C directory manually, and re-ran the same build (after a reboot, because stopping the TaskWindow seems to have created a situation that won’t allow another one to run – it locks the machine). I noticed that the RiscOS directory contains a directory Install, and one called Install/ROOL/Disc. I take it this means something is creating Linux-style paths without translating slash to dot?

I think it’s building. I took !CoreUtils out of the Apps folder.

I don’t know if mkdir can create multiple directory levels at a time.

The ROOL one can (that’s what the -p switch does).

I noticed that the RiscOS directory contains a directory Install, and one called Install/ROOL/Disc. I take it this means something is creating Linux-style paths without translating slash to dot?

I believe the ROOL mkdir works exclusively with RISC OS style paths. So it sounds like you’ve got a unixy one somewhere which is interpreting “Install.ROOL.Disc” as a Unix path and translating it to a RISC OS path of “Install/ROOL/Disc”.

!CoreUtils contains the unixy mkdir, among lots of other stuff. IIRC it’s what you get (or need) along with GCC, the new version of which I installed a few months back.

Built OK now. Thanks for everyone’s help.

Compatibility between DDE and GCC is still a subject for a bit of work, I think.