Building Sources

Hi I have just updated my DDE to the latest version Norcroft RISC OS ARM C vsn 5.70 [12 Oct 2012]
and thought I would have a go at building the sources so I downloaded the BCM2835DEV source archive
and followed the instructions on the web page Beginner’s guide to ROM builds. I get the following errors
with todays build.
Error: expected ‘;’ or ‘,’ – inserted ‘;’ before ‘*’
“vc04_services.interface.vchiq_arm.c.vchiq_shim”, line 660: Error: declaration lacks type (assuming ‘int’): ‘setup’
“vc04_services.interface.vchiq_arm.c.vchiq_shim”, line 660: Error: expected ‘;’ or ‘,’ – inserted ‘;’ before ‘*’
“vc04_services.interface.vchiq_arm.c.vchiq_shim”, line 660: Fatal error: Too many errors
Compilation abandoned.
AMU: * exit (1) *

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

Error running make rom_link on module ‘VCHIQ’.
Fatal error running make rom_link on module ‘VCHIQ’.
Batched errors…
Error running make rom_link on module ‘VCHIQ’.

I then tried downloading the tungsten 5.16 stable archive and get the following:-

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

Error running make rom_link on module ‘USBDriver’.
Fatal error running make rom_link on module ‘USBDriver’.
Batched errors…
Error running make rom_link on module ‘USBDriver’.

Am I doing something wrong?

TIA Terry

and thought I would have a go at building the sources so I downloaded the BCM2835DEV source archive

That seems like a good idea so I thought I’d try the same with the tools from my NutPi SD installation. However, so far I’m nowhere near your result. Firstly, the download filename inexplicably had the . (/?) bz2 removed, thus leaving it at a /tar yet the same size as the download, hmmmm.

Next I downloaded !UnTarBZ2, & opened it to the icon bar, thinking that may help. Download archive again. Same result.

Ok, download archive on OS X mac, un-bz,tar etc. & it’s now about 114 meg’s which looks more promising. Move that over to RPI, & now it’s unarchiving on there, so when it’s done that I’ll see what happens next.

I have problems building on beagle. I get prostmortem from !Common env file..

I’ve been trying to build tungstendev for 3 days – I’m getting close :-)

If you are using !untarbz2 to dearchive then it doesn’t work. Dearchiving tungsten 5.16 should work but between that and the current developement archives rool must have changed the tar creating program they use as it uses a different scheme for storing long pathnames. I’ve just wrote a replacement for the tar part of untarbz2 which fixes this. I posted it to rool last night.

The other problem I’ve found so far is that certain inetlib files include errno.h and sys/errno.h and they both define EFBIG but to different values so the build fails because of this.

A couple of points I learned from hours of wasted time – it may help others:

1) after dearchiving with untarbz2 ensure that !setpaths in the AcornC/C++ folder has been seen.

2) Open the folder that you specified as the target for the dearchive by untarbz2 and you should see a folder (in my case TungstenDev). Open that and then open Prepare. Run Prepare.!run and say yes to all questions asked. (Maybe someone can tell me why it isn’t !Prepare so you just clicked on that?)

3) DO NOT MERGE ANY FOLDERS

4) RESET THE MACHINE – so that it forgets AcornC/C++. If you boot AcornC/C++.!setpaths at startup this may cause problems.

5) Go to the folder containing Prepare and run Apps.!builder

6) when asked to register a build tree drag in the folder containing Prepare (In my case TungstenDev) and save.

7)Click on the !Builder icon and set the build directory from the pop up menu – it should be the one you just registered. Then select the environment. Despite the fact that you only downloaded the archive for one machine the environment popup shows them all. You should pick the on relevant to your archive – in my case ROOL.Tungsten. This process also sets the environment variables for the compiler (similar to !setpaths in AcornC/C++).

8) Now you can compile the rom to do this you need to tick Export headers,Export Libraries,Export Resources,make rom, install rom, join rom. You can do them all at once or one at a time but the order is important.

I’ve been trying to build tungstendev for 3 days – I’m getting close :-)

I am not alone then :-)

I have been basically doing what you describe above with no success but I have been
using !untarbz2 so perhaps that is the problem, On one of the earlier BCM2835DEV builds
I did notice the EFBIG definition errors. Tungsten 5.16 still does not work here?.

Will keep at it :-)

I finally got it to compile this morning. I browsed the online cvs repository for where the build process failed (the rom_link stage of aun.net) and found that it had been changed 2 days ago so I downloaded the archive again and after running Prepare.!run I added

#ifdef EFBIG
#undef EFBIG
#endif

before

#define EFBIG 27 /file to large/

to mixed.riscos.sources.lib.TCPIPLibs.header.sys.h.errno

and everything built perfectly.

I have problems building on beagle. I get prostmortem from !Common env file..

Yeah, I know :( The problem is that we need to recompile grep to make it ARMv7 safe, except that in order to do that we also need to update to a newer version of GCC, which also requires us to fix up and recompile a bunch of libraries. Plus to keep the build pipeline consistent we’d have to make sure that new version of GCC is in CVS, which will then require the sources to be there as well, etc, etc. So it’s not a trivial fix, but it’s a bit embarrassing that we’ve left it broken for so long. I’ll take a proper look at it this weekend and see if I can get everything working.

All the problems with !UnTarBZ2 are also a bit embarrassing, although my hands are tied on that one since I can’t upload a new version to the site.

2) Open the folder that you specified as the target for the dearchive by untarbz2 and you should see a folder (in my case TungstenDev). Open that and then open Prepare. Run Prepare.!run and say yes to all questions asked. (Maybe someone can tell me why it isn’t !Prepare so you just clicked on that?)

Apparently there were some issues with CVS not liking a folder in the root of the repository which begins with a “!”.

Yeah, I know :( The problem is that we need to recompile grep to make it ARMv7 safe

Is there a ARMv7 grep somewhere I can grab?

Is there a ARMv7 grep somewhere I can grab?

From riscos.info. You also need to use the perl binary from DDE.
Fails on SharedRISC_OSLib: cannot open syms.A_Entries1 for I/O redirection.

I have made some improvements to my Gnu tar app, but I think it has been capable of expanding BCM2835DEV in the past OK.
It might be handy for you to make a comparison.
It will be about 30% faster if verbose is turned off.
If you use Ram for the temp, make sure it can take about 120MB or so for the bz expansion.

http://homepages.woosh.co.nz/ron.may/tarctrl.zip

Fails on SharedRISC_OSLib: cannot open syms.A_Entries1 for I/O redirection.

solved. egrep needs unix paths with “/” instead of “.” in the input file.. Now timestamp fails but that will solve when I get a proper cmos widget. There are still some components that doesn’t build ( and hasn’t for a long time) romfonts for example.

Yiha .. There where some modules I disabled , but enough
for my work .. :D

Starting phase join …
romlinker: version 0.04 (31 Jul 2011)
romlinker: Standard ROM image construction
romlinker: Image has 1848981 bytes spare (1805.65K)
romlinker: crc16=104c

==================
Finished ROOL.OMAP3 build : Fri Jan 2 01:32:53 1970

I have problems building on beagle. I get prostmortem from !Common env file..

Yeah, I know :( The problem is that we need to recompile grep to make it ARMv7 safe, except that in order to do that we also need to update to a newer version of GCC, which also requires us to fix up and recompile a bunch of libraries.

As an update to this, I’ve now successfully fixed up and rebuilt enough of the tools to get the source building properly on OMAP. But there are still a couple more tools that need fixing – so I’m going to try and get those fixed before checking anything in, so that we don’t need to keep two different versions of GCC knocking around.

I’m trying to compile BCM2835Dev on a raspberry pi Model B, with the 17/3/13 development rom.

Everything appears to be fine until the process tries to link the VCHIQ module. Then it pops up lots of errors and abandons compiling. I have no knowledge of CVS, makefiles etc therefore I have no clue what went wrong. Hopefully my experience shared might help those in the know.

I have saved the entire output of the task window in case it is helpful.

Cheers.

@Jeffrey

Have you managed to get everything fixed to allow building on OMAP?
I’m happy to test anything for you!

Not yet, I’m afraid. I’ve been caught up with working on something else (Kinetic support for IOMD), but that’s pretty much done now, so I should be able to return to these build issues sometime this weekend.

Ah of course! Sprow said he was sending my Kinetic your way. Hope it’s been useful!

No rush with the updated build tools.
Take some time off and enjoy the bank holiday weekend!

Update: I’ve been given the all-clear to check my changes into CVS to fix all the stuff that’s stopping us from building ROMs on ARMv7 machines. However it might be a few days until I get around to it, as I need to merge in the latest changes from CVS and then do one final set of tests, and I don’t have much spare time at the moment due to work pressures.

My changes are now in. So assuming I didn’t miss anything (I’ll check when I have a spare minute), it should now be possible to build ROMs on ARMv7 machines without any issues.

Just to report that building ROMs on a Pandaboard now works flawlessly every time with alignment exceptions turned on. Build time for an OMAP4 rom takes 6 min 30s.

Nice!

Just to report that building ROMs on a Pandaboard now works flawlessly every time with alignment exceptions turned on.

Just to add to this – I only just noticed the comment in the “how to build” document that says alignment exceptions should be turned off for !Builder.
I didn’t, it worked.

Build time for an OMAP4 rom takes 6 min 30s.

Is that for a complete build from clean/clean all to ROM image arriving? Jeez, I think the Pi took around two hours! (and I gave up on waiting for the Beagle – slow USB stick!)

What sort of SD card are you using? A class 10? That’s probably where the difference lies – mine’s a generic (class 2? 4?) SD card.

Just to add to this – I only just noticed the comment in the “how to build” document that says alignment exceptions should be turned off for !Builder.
I didn’t, it worked.

Ah, I didn’t the page said that. I’ve now updated it.

Is that for a complete build from clean/clean all to ROM image arriving?

The time is for a complete build from scratch.

What sort of SD card are you using? A class 10? That’s probably where the difference lies – mine’s a generic (class 2? 4?) SD card.

After a bit of experimenting I found that a FAT32 formatted SSD using Fat32Fs was the fastest. If you have slow disk media it has a massive impact on the build time.
The fastest media to use would be a RAM disk but to build the ROM needs a RAM disk size of 384MiB. I did try changing the limit from 128MiB to 384MiB but I get a freeze as soon as the desktop is displayed.

My Pandaboard is clocked at 1600MHz and the memory is overclocked from 400MHz to 532MHz.

My changes are now in. So assuming I didn’t miss anything (I’ll check when I have a spare minute), it should now be possible to build ROMs on ARMv7 machines without any issues.

While testing the DiscDev archive I noticed it’s still using the non ARMv7 safe versions of some of the build tools. Alignment exceptions still need to be turned off to build DiscDev.