iMx6 ROM Build Failure
Steffen Huber (91) 1945 posts |
The bigger question is: if you have comparatively few people contributing, is it a wise move to make the barrier of entry for contributions even higher, for unclear (and unexplained) gains? |
Paolo Fabio Zaino (28) 1795 posts |
If the expense of the paid compiler is an obstacle, let’s revisit the idea with a similar spirit: “Given the interest expressed here, how about someone from our community steps up to convert the RISC OS build system to use AASM and GCC? It would be a great resource for everyone.” This suggestion is rooted in the same principle: In our open-source community, if no one steps up to tackle a challenge, it will most likely remains unaddressed, because the people actively supporting RISC OS in terms of coding/refactoring/bug fixing/improvements is small (very small!). I also want to add that continually pressing ROOL to work for completely free and on what we want isn’t the most constructive approach. We’re not talking about simple requests like switching PackMan distribution from HTTP to HTTPS for community safety, or sharing tips for changing a button color with a new API, or even fixing a minor bug in DDT. ROOL has already shown considerable effort, especially with their discount period. It’s important to remember the context here. The FSF has the backing of major players like IBM, RedHat and others, providing substantial funding. RISC OS, on the other hand, doesn’t enjoy such support. While we do have dedicated volunteers, the community isn’t vast enough to sustain extensive development and support. The stark reality is that only a few entities like RComp, CJE, Elasar, RISCOSbits, and a handful of others truly rely on RISC OS, no one else does, not even the folks that scream how “modern” it is or how we should make it 64 bit. We need to be realistic about our expectations and what can be feasibly achieved with the resources we have. The essence of Open Source is community-driven support and maintenance, but that requires a certain critical mass which, in RISC OS’s case, is a challenging aspect. |
Paolo Fabio Zaino (28) 1795 posts |
The updates to the DDE are driven by a blend of immediate needs and long-term improvements. They clearly focus on what can realistically be fixed or enhanced in line with ROOL’s roadmap for both application development and RISC OS itself. It’s about enhancing both the app development process and the overall RISC OS coding/building process. This isn’t hidden knowledge. In fact, I even mentioned in a video the fixes in DDT by ROOL following an issue I encountered in a previous tutorial. Sometimes, the changes we see are the ‘low hanging fruit’ – those tasks that can be tackled given the limited time available to the developers. Other times, more substantial changes roll out, reflecting efforts that have been in progress for a while. It’s a balancing act between immediate feasibilities and strategic, long-term development goals all within the frame of a really small team of contributors.
The real challenge in contributing to the RISC OS codebase isn’t so much about the paid development environment; it’s more about the skillset and time equired. Finding individuals with the knowledge and experience in ARM assembly or a deep understanding of the existing sources is rare (certainly very rare with free time available). Most people proficient in coding are more familiar with environments like GCC rather than ObjASM or DDE C. While adapting to different development tools can be manageable, overcoming the initial knowledge gap in system-specific programming is the real hurdle. In today’s tech landscape, many are skilled in languages like JS, TypeScript, Python, Lua, Java, etc., but operating system development and support is a different ball game (especially for an OS from the 80s) compared to user-space application development. It requires a specific set of skills and understanding, which is not as commonly found in the broader programming community. With RISC OS not being something that is competitive (or even relevant) in any specific market, it really doesn’t help to get the right folks motivated. [edit] The part that doesn’t make much sense IMHO, is that most of DDE is still not open sourced. That is certainly concerning, given that people are asked to pay for the continuos improvements. That is probably something that ROOL should explain a bit better somewhere. Just my thoughts. 1 This doesn’t mean RISC OS should not be open sourced, Open Sourcing it is a warrantee on the “investment” people do when paying small fees to have support/maintenance/improvements on it. If something goes wrong, they have all the work done till that moment in source form. |
Steve Pampling (1551) 7967 posts |
Pet hate there. The phrase you want is “Maybe you should have read the bit about” I do agree with the sentiments, after all when you compare to other systems/OSs the upgrade and necessary regularity of that upgrading is hardly going to encourage extra developers. I was watching a recorded session with Linus Torvalds the other day, in which he spoke of the many developers, ranging from those who submitted one single patch many years ago and nothing since (although they were still around) whereas others were constantly submitting over many years – all were welcome. What he didn’t mention was that they were all able to use a free compiler. Making them pay, regularly, would probably reduce the input. |
Paolo Fabio Zaino (28) 1795 posts |
But something Linus mention quite often is the real essence of Open Source, it’s not a charity, we fix what we need to be fixed for ourselves (because we rely on it) and maintainers ensure that the situation doesn’t get out of control. With Open Source foundations getting substantial funding compared to what ROOL or ROD (or even both combined together) can even dream to reach. So, how are we envisioning to apply such a model to RISC OS, so that then we can get DDE for free like GCC? One way to address this would be to focus the small resources, to improve RISC OS to become a bit more relevant in some market (if this is at all possible), and then slowly go from there. Otherwise I am really struggling to understand what is being asked here, just work for free because “I” demand it? Maybe I am not as smart as you guys are, so can someone please enlight me? (Genuine question) |
Steffen Huber (91) 1945 posts |
Personally, I am just asking for better communication by ROOL. It would be nice to have answers for questions like “Why are you developing a second new network stack” or “Why is it a good idea to introduce C18 features into the RISC OS source tree, rendering slightly older DDE versions useless for OS development” or “Why are new RCs not announced properly”. Or “How much revenue does DDE generate and can we please find an alternative way to provide that revenue”. Basic stuff like that. |
Rick Murray (539) 13440 posts |
Yay! We’re on to page 2, so it doesn’t go off the screen in NetSurf. ;)
Sadly, I was born a little too late. I’m used to electrics using the Third Rail (as I am from “dahwn sahf”) or those diesel monstrosties that sounded one lose bolt away from exploding.
Is that a surprise? When I was young (I can remember before the dinky little phone plug was invented) calling anybody was a gamble. You paid by distance, time of day, day of week… Mom had a little gizmo that set under the phone and was programmed with plastic punch cards (!) that tried to keep track of how much the phone bill would be. I don’t think Prestel failed (whereas over here Minitel was a huge success) not because of the famous mailbox hack, but because everything was so bloody expensive.
I don’t, because I’m an introvert. But if I wanted to, I could call landlines in 110 different countries, and mobiles in the EU, UK, USA, and Canada…for free. It’s included since my phone is a VoIP one. The limitation? Of course there’s a limitation. 3h/max per call (but you can call back) and no more than 250 different numbers per month. It’s designed to not be restrictive to ordinary humans, but potentially restrictive to business (who can cough up more) and very restrictive to spammers.
Does the cost of the DDE help fund the development of it? Or, to put it in different terms, if ROOL dropped the DDE onto their site as a free download, what’s the impetus to continue developing it? Granted, the sales aren’t likely to amount to much (as most of us prolly qualify for the half price upgrade by now) but it’s better than a kick in the teeth.
Zing! ;)
There’s the first problem.
That’s why I don’t think making the DDE free would change anything. Some people were freaking out about the Castle licence and how it wasn’t open enough for them. Well, the sources are now open in an OSI-friendly way and, well, where are these people now? Where are the hoardes of developers that were put off by the licence? The second problem is that it’s a massive pile of assembler to build an OS written with an ‘80s mindset. Which pretty much means it’ll be totally alien to people who never saw the likes of a BBC Micro or Archimedes at school. It won’t matter if the DDE is free and they could rent Jeffrey to come and hold their hand, they’ll still look at the source with eyes glazing over as they start to understand exactly how far the code is from their comfort zone.
Just don’t kidnap that guy’s daughter…
I wonder if their licence permits such a thing? I would imagine hell would freeze over before the compiler is ever opened up – certainly they’d have to go kick whatever remains of Norcroft to see if anybody has objections. If you thought the ownership of RISC OS was a mess… Given the heritage of the DDE, it’s entirely possible that there are limitations on what they can do with it. It’s not insurmountable (look at the PRM font issue for an example of the ridiculous little problems that crop up) but sorting it out may not exactly be a priority. As has been noted, small development team.
On the other hand, if the tools are open sourced, what’s the incentive to bother paying for any new versions when you could just yank the code and build the newer version for yourself? Selling open source stuff might scale in the Linux world, but here in the RISC OS world I would imagine that everybody who would be interested in using the DDE could also build the DDE with the DDE… That being said, I think it would be good to open up parts of the DDE. For example, people use CMunge because of deficiencies with CMHG that have never been addressed. If CMHG was open, then these things could be tackled as personal-itch projects.
The way that is often handled in business is an escrow service.
I don’t think there’s any sort of ill will here. Nobody is intentionally hiding anything, it’s most likely a combination of a strong desire to not want to announce something before it is in a good enough state to show off (I think this is ultimately why two stacks) and the fact that those who are involved are juggling numerous hats at the same time and possibly other jobs and commitments. So, yeah, messages get mixed and opportunities lost. Just be glad there are those who still give a shit. This isn’t Linux. This isn’t Windows. This is a little OS from the late 80s/early 90s that is still going despite it all. If there are a few roadblocks and hiccups along the way… well… any volunteers to step up to help improve things? |
Colin (478) 2433 posts |
The same reason they develop it now to make it easier to port software. |
Mike Howard (479) 190 posts |
Ok, back on to the original matter of the build failing. Having installed DDE31c, I seem to be in a wiorse piosition than I was :-)
and a trillion more errors until it bails. So, unless the provided DDE is incomplete (unlikely) I have, despite following the ‘howto’ and previous notes, done or not done something I should or shouln’t have! Any obvious likely blooper anybody is aware of? |
Stuart Swales (8827) 1257 posts |
Have you deleted the previous iMX6 build directory and created afresh? On first run it ‘helpfully’ caches copies of the tools. |
Mike Howard (479) 190 posts |
Yeah, I did. I started with a completely fresh source tree but I noticed the version and didn’t think that was right but I had also moved the original DDE completely out of the way. I’ll start from a completely fresh disk image installation and see what happens. Something might be lurking that I have forgotten about. |
David Pitt (9872) 306 posts |
That version is from DDE28c These diagnostics will show what version of the DDE is on the case. *show SetPath* SetPaths$Dir : SCSI::SSD120.$.Progm.AcornC/C++.AcornC/C++.!SetPaths *cc --version Norcroft RISC OS Arm C vsn 5.91 [23 Feb 2023] * Builder may be worth a restart. |
Stuart Swales (8827) 1257 posts |
It’s worth keeping all copies of the DDE buried with different versions kept well apart so that you can select the one you actually want to use rather than the system booting something ‘convenient’. |
Mike Howard (479) 190 posts |
Correct. I had forgotten that the first build attempt, days ago, was made with the git folder mounted across the network. Hence, the old tools had been copied across during the ‘prepare’ process. It became clear when the same errors were thrown on a completely fresh RISCOS install but using a copy of the git folder. I’ll try again.
Yeah, good point. |
Mike Howard (479) 190 posts |
Well this plot thickens. ot a write error of sorts …
syms.A_Entries is not created and yet, on the penultimate line, syms.C_Entries is created |
Mike Howard (479) 190 posts |
By the way, how do you get block quotes to encompass blank lines :-) |
Steve Pampling (1551) 7967 posts |
The answer to that question and more you may not have thought of yet is Here But briefly < blockquote > and the < /blockquote > (Remove the space inside the < elements) |
Mike Howard (479) 190 posts |
Ah, a working link. I had tried the ‘redcloth’ one at the bottom of the page but that no longer directs correctly. |
David Pitt (9872) 306 posts |
There is a remove line here for syms.A_Entries1 SharedRISC_OSLib (Sources.Lib.RISC_OSLib)... amu -E rom_link ADDRESS=4229301016 LINKDIR=RAM::RamDisc0.$.ROOL.RiscOS.Install.ROOL.iMx6.Lib COMPONENT=SharedRISC_OSLib TARGET=RISC_OSLib do <Perl$Dir>.perl build:xtentries > syms.C_Entries kernel.s.k_entries kernel.s.k_entries2 clib.s.cl_entries clib.s.cl_entry2 clib.s.cl_entry3 clib.s.cl_entry4 clib.s.cl_entry5 print rlib.swi { >> syms.C_Entries } do <Perl$Dir>.perl build:xtentries > syms.A_Entries1 kernel.s.k_entries clib.s.cl_entries egrep -v "^(0x00000000 . )?_swix?$" < syms.A_Entries1 > syms.A_Entries remove syms.A_Entries1 do <Perl$Dir>.perl build:xtentries > syms.Entries kernel.s.k_entries kernel.s.k_entries2 clib.s.cl_entries clib.s.cl_entry2 clib.s.cl_entry3 clib.s.cl_entry4 clib.s.cl_entry5 rlib.s.rl_entries print rlib.swi { >> syms.Entries } (The code could be wrapped in There are no further entries in my log for syms.A_Entries1. These files are present. RiscOS.Sources.Lib.RISC_OSLib.syms.A_Entries RiscOS.Sources.Lib.RISC_OSLib.syms.C_Entries RiscOS.Sources.Lib.RISC_OSLib.syms.Entries RiscOS.Sources.Lib.RISC_OSLib.syms.RISC_OSLib This is what happens next. | copy syms.Entries RISC_OSLib:o.abssym ~cfr~v copy syms.C_Entries RISC_OSLib:o.c_abssym ~cfr~v copy syms.A_Entries RISC_OSLib:o.a_abssym ~cfr~v | SharedRISC_OSLib: rom_link complete
Is that a typo? |
Steve Pampling (1551) 7967 posts |
The site disappeared some while back and unfortunately those with the info of a working site don’t have edit access to the ROOL site, and those with edit access to the ROOL site either haven’t read any of the posts that identify the three files that need changing, or have read but not implemented. |
Mike Howard (479) 190 posts |
Not here. The complete output here is
If it is, it’s not one of mine. Maybe a typo in the source? Only A_Entries1 and C_Entries are present in ‘syms’ No sight of A_Entries Editted to correct the existance of A_Entries1 and not A_Entries |
Sprow (202) 1129 posts |
There is a remove line here for syms.A_Entries1 My first port of call is reading the error message tea leaves, and in this case I think it’s trying to tell you that syms.A_Entries1 can’t be opened for reading because it doesn’t exist (as opposed to what David’s saying: that 3 lines later in the makefile it’s actively removed, and hence had the makefile run to completion you wouldn’t expect to find the file in the syms directory anyway). I assume you have R/W permission for that directory, so it’s not locked or anything silly if it was copied off a network share. Given your earlier up to date yet not updated tool issue it’s also worth checking there isn’t another copy of Perl hiding somewhere. The build system needs a very specific version of perl; here
ie. the copy of perl is the one inside the build tree, adjacent to the sources and RiscOS.Library, not some later version somewhere else. |
Steve Pampling (1551) 7967 posts |
That’s “unfortunate”1 as it introduces some interesting failure modes. 1 Let’s put that in the same “undocumented feature” category as a medical monitoring system which allowed use of ‘demo mode patient data’ on a client device to test its connection to the server in revision B and disallowed it in revision 42 thus causing a two-month delay in upgrade/migration when the established method of testing by the medical equipment support guys showed a failure on the new setup on top of the discovered bug in the proxy arp capabilities. 2 No, I don’t know why the revisions went from lettered to numbered |
Mike Howard (479) 190 posts |
Yep, as mentioned above, the file does exist and is readable. It does not get deleted by the following line of the makefile, due to the error. The error seems like a red herring as the file exists and is readable. The output file ‘syms.A_Entries’ does not get created, due to the grep command failing. Perl is located in the Apps directory where you state it should be. Edited to say I started afresh with a clean RISC OS image and a fresh DDE install to avoid any ‘hidden’ surprises. |
Mike Howard (479) 190 posts |
Uhm. What version of grep is required? egrep here accesses directories using unix notation. i.e. file in current location . ;
file in sub directory syms ;
The failures produce the
or create an unintended file dependent on usage. |