iMx6 ROM Build Failure

I’ve just tried building the ROM, from git, and it fails. The first failure is a hang at

ROMFonts (Sources.Video.Render.Fonts.ROMFonts)…
amu -E -k rom COMPONENT=ROMFonts TARGET=ROMFonts
sed -e ‘s/\x23.*$//’ > Fonts.Encodings.UTF8

This is as a result of sed not interpreting the supplied input file correctly. Hardcoding the actual filename gets past that error.

It then baulks upon ‘Starting phase install_rom’

HAL_iMx6 (Sources.HAL.HAL_iMx6)…
amu -E install_rom INSTDIR=SCSI::fairy.$.SRC.iMx6.RiscOS.Install.ROOL.iMx6.RISC_OS COMPONENT=HAL_iMx6 TARGET=iMx6
objasm -PD “VideoInHAL SETL {FALSE}” -depend !Depend -PD “standalone SETL {TRUE}” -PD “MergedMsgs SETS \”o.ResData.iMx6.Messages\"" -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd “APCS SETS \”APCS-32\"" -pd “Machine SETS \”CortexA9\"" -pd “UserIF SETS \”Sovereign\"" -APCS 3/nofp/noswst -o o.DBell s.DBell
ARM AOF Macro Assembler 4.05 (Acorn Computers Ltd) [19 Mar 2018]
Error: File “iMx6q.hdr” could not be opened

There are also tons of preceding errors throughout tyhe build, of the nature

“C:h.stdlib”, line 378: Serious error: objects of type ‘void’ can not be initialised
“C:h.stdlib”, line 441: Serious error: illegal ‘void’ object: ‘_Noreturn’

Anybody got any pointers?

sed -e ‘s/\x23.*$//’

That looks familiar

sed is too old.

What version of the DDE is in use? iMx6 built to completion here with DDE31c.

HTH.

Thanks for the link.

The sed being used, to the best of my knowledge, is the one provided from git, downloaded today, v4.0.7.

The DDE I’m using is DDE29, c I think. Why would the version of the DDE be relevant in this context? Do I need to buy a new version of the DDE for each version of RISC OS?

Any ideas on the stdlib header errors?

*which sed
File: RAM::RamDisc0.$.ROOL.iMx6.RiscOS.Library.Unix.sed
*sed --version
GNU sed version 4.0.7

So it is not as simple just the sed version, but it does build with DDE31c

ROMFonts (Sources.Video.Render.Fonts.ROMFonts)...
amu -E  -k rom COMPONENT=ROMFonts TARGET=ROMFonts
sed -e 's/\x23.*$//' Fonts.Encodings.UTF8Full > Fonts.Encodings.UTF8
do mkdir -p o
objasm -depend !Depend    -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"CortexA9\"" -pd "UserIF SETS \"Sovereign\"" s.ROMFonts -o o.Sovereign
Arm AOF Macro Assembler 4.13 (Acorn Computers Ltd) [23 Feb 2023]
do mkdir -p rm.Sovereign
link -bin -o rm.Sovereign.ROMFonts o.Sovereign
settype rm.Sovereign.ROMFonts &FFA
ROMFonts: rom module built

It does not baulk here either.

Starting phase install_rom ...

HAL_iMx6 (Sources.HAL.HAL_iMx6)...
amu -E  install_rom INSTDIR=RAM::RamDisc0.$.ROOL2.iMx6.RiscOS.Install.ROOL.iMx6.RISC_OS COMPONENT=HAL_iMx6 TARGET=iMx6
link   -o linked.iMx6 -bin -base 0xFC000000 aof.iMx6
copy  linked.iMx6 RAM::RamDisc0.$.ROOL2.iMx6.RiscOS.Install.ROOL.iMx6.RISC_OS.iMx6 FR~C~V~N
iMx6_HAL: HAL installed

Any ideas on the stdlib header errors?

The stlib header errors do not appear in the logs here.

Do I need to buy a new version of the DDE for each version of RISC OS

In my experience the DDE can become out of date. I just update anyway. Pragmatically DDE31c does work with this source, whereas a build here with DDE29c stalls at that sed line.

A fuller answer will have to come from elsewhere.

Cool. Thanks for taking the time.

“C:h.stdlib”, line 441: Serious error: illegal ‘void’ object: ‘_Noreturn’

I think from the ‘_Noreturn’ error it’s a lack of C18 capabilities introduced in the DDE30 C compiler (late 2020).

Ah, ok. Sort of makes the DDE a subscription service then!

sed is too old.

I think it is not sed but what was said at the MUG show was that the version of amu (or something like that) in DDE29 could not expand a ‘$…’ argument because a new feature (present since DDE30?) had started being used and so sed was presented with a blank argument and the compilation halted for the user to type the magic word (it knew the argument was blank and so waits for user input).

Ah, ok. Sort of makes the DDE a subscription service then

There are always going to be compatibility breaks from time to time – when the SharedCLibrary in the ROM began implementing the functions for C18 support it’s not unreasonable for it to expect to be compiled with a C compiler with C18 support!

it’s not unreasonable for it to expect to be compiled with a C compiler with C18 support!

Define unreasonable. I have no objection to paying for upgrades for improved products, I purchased the DDE from Castle when I purchased an Iyonix way back. I’ve paid to upgrade it numerous times over the intervening years.

Actually making a piece of (fairly recent) software obsolete is though, in my opinion, unreasonable. Afterall, the sales blurb encourages it’s purchase in order to work on RISC OS.

Hey ho!

There are always going to be compatibility breaks from time to time

No. There are projects out there which adhere to very strict guidelines wrt the C standard and tools compatibility in general. If ROOL chooses to not have such guidelines, or explicitly want to practice “eat your own dog-food” and therefore try to use new DDE features ASAP, that is a concious decision that has pros and cons.

I have not seen any such guidelines, so maybe it is “by accident” or “random.” Is there documentation on which changes introduced to RISC OS need which version of the DDE?

when the SharedCLibrary in the ROM began implementing the functions for C18 support it’s not unreasonable for it to expect to be compiled with a C compiler with C18 support!

I don’t see any connection between implementing a standard library and the compiler/tooling used to do so. It is not unheard of that a compiler runtime is implemented in a completely different programming language.

What would you count as “fairly recent”? It’s not unusual that a development environment is a moving target. The DDE is too, albeit a very slowly moving target, and as such it is quite reasonable to expect that when new functionality is added to the compiler, that something will start using it. By consequence, earlier versions will be obsoleted. This isn’t so unusual, VisualBasic 5 (February 1997) couldn’t do some things that VisualBasic 6 (June 1998) could do, so that development environment was effectively obsoleted in only a year and a half.

Do note that C18 implies 2018, which was over half a decade ago, and DDE30 with support for this stuff in 2020… well, it’s nearly 2024.
Like I said, a very slow moving target, but moving all the same.

If you’re feeling particularly masochistic, you could – I suppose – diff the new files with their older counterparts to see what needs to be hacked with in order to get it running on your older compiler?

What would you count as “fairly recent”?

2019

If you’re feeling particularly masochistic, you could – I suppose – diff the new files with their older counterparts to see what needs to be hacked with in order to get it running on your older compiler?

I take it that was an attempt at humour?

Minimum requirements to build an OS image or a Kernel do change overtime, sometimes they can change even frequently (for various reasons).

Let’s keep in mind that RISC OS is maintained by a dedicated but small group of individuals. So, expecting support on par with a platform like Linux might be unrealistic and could lead to disappointment.

That said, given the interest expressed here, how about someone from our community steps up to create a Wiki page with relevant information? It would be a great resource for everyone.

For inspiration, check out one of the “official” pages detailing the Linux Kernel build minimum requirements: https://www.kernel.org/doc/html/next/process/changes.html.

This is scertainly a wonderful way for us to collaborate and support the RISC OS community, pooling our knowledge and resources where official support might have its limits.

Hmm… After the big table listing the versions, it says…

The gcc version requirements may vary depending on the type of CPU in your computer.

;)

I think the Big Question is what actually drives the updates to the DDE? Is it one overworked and underappreciated developer trying to bring newer and better facilities to us programmers, or is it mostly done in order to make it easier to build the OS itself? If the latter, this would imply that one would always need a “recentish” version of the DDE in order to be able to build the OS. If the former, then “it depends”.

2019

Aw, man. Them’s pre-Covid days. That’s forever ago.

What the **** has covid got to do with it?

An expression that we have different ideas of what “fairly recent” means.

Hmm… After the big table listing the versions, it says…

The gcc version requirements may vary depending on the type of CPU in your computer.

I’m not sure that quoting the changing compatibility requirements of a free compiler over time does much to justify the same in a paid item.
Perhaps if the update was a cheap/free patch, the justification would be easier.

As I recall, some of the breaking changes involved use of macro references in the source, where the only availability of the macro(s) was with a newer compiler version.

An expression that we have different ideas of what “fairly recent” means.

Well, if you sell something to somebody in 2019, and then obsolete it in 2020, I’d say that was unreasonable.

No big deal, I might do as you suggest above and ‘fork’ RISC OS for the poor :-)

somebody in 2019, and then obsolete it in 2020

Were you outside of the window of being eligible for an upgrade?

Perhaps if the update was a cheap/free patch

This I’d agree with. It does seem… disappointing…that the official compiler that builds the OS can’t build the OS. Hmm… Impediments, not good. 🤔

Were you outside of the window of being eligible for an upgrade?

I received the last minor update to the major version. My point is, at what point, whilst selling the DDE in 2018, 2019 did they know that in October 2020 they would add the latest C18 standard dialect?

As I said, hey ho!

Many people seem to just take ROOL as a free resource. Well, it isn’t.

Many people seem to assume that stuff written many years ago will still do everything. Well, it doesn’t. The ARM instruction set keeps changing; instructions get deprecated. The C language has undergone many changes since K&R.

The DDE was never free, nor could any version of it ever be expected to remain up to the minute – minutes keep passing by in huge numbers.

In short, the world keeps changing, and some parts of it require that we pay money to keep participating in it – and in driving it forward.

Nearly 50 years ago, quite by chance, I had a ride in an 1896 Daimler. It was open topped, clearly very recently descended from a horse-drawn vehicle. This event has stayed with me through all these years. As a car, it was very primitive; but someone bought it, which showed there was a demand and financed development of a better one. Fortunately there have been many developments over the years – and there will be many more. (Think of the change to electric, happening now.)

I went to watch a steam train this morning. When I was growing up, steam trains were ubiquitous. Then we went over to diesel and electric locomotive-hailed trains. Then we went over to multiple units, sets that can be driven from either end. And countless improvements in comfort and safety.

When I was young, telephone ownership (well, yes, it was rental really, but the same thing applies…) was by no means universal. Eventually everyone had one, then everyone has a mobile. Now I think I’m about to give up the land line because we never use it.

Thanks for all of that, really interesting stuff.

Maybe you should of read the bit about when I originally bought the DDE from Castle and purchased updates over the years. What bit about that suggests I want something for free?

In fact, I’ve already purchased a new upgrade!