DiscDev source archive doesn't compile

Anyone else managed to compile the DiscDev source archive. A download today fails for me as the mbedtls library doesn’t compile.

cc -Wp -c -depend !Depend -throwback -DMBEDTLS_CONFIG_FILE="\"h.ro_config\"" -DRISCOS -ITCPIPLibs: -ff -fah -o o.bignum c.bignum
Norcroft RISC OS ARM C vsn 5.72 [07 Apr 2016]
"c.bignum", line 771: Serious error: attempt to apply a non-function
"c.bignum", line 776: Serious error: attempt to apply a non-function
"c.bignum", line 777: Serious error: attempt to apply a non-function
c.bignum: 0 warnings, 0 errors, 3 serious errors
AMU: *** exit (1) ***

Anyone else managed to compile the DiscDev source archive. A download today fails for me as the mbedtls library doesn’t compile.

It’s good here, built on a Titanium, but it is a later DDE, DDE28d, C vsn 5.78, though that may not have anything to do with it.

c.blowfish: 1042 warnings, 0 errors, 0 serious errors
cc -Wp -c -depend !Depend  -DMBEDTLS_CONFIG_FILE="\"h.ro_config\"" -DRISCOS -ITCPIPLibs: -ff -fah -o o.bignum c.bignum
Norcroft RISC OS ARM C vsn 5.78 [05 Feb 2019]
cc -Wp -c -depend !Depend  -DMBEDTLS_CONFIG_FILE="\"h.ro_config\"" -DRISCOS -ITCPIPLibs: -ff -fah -o o.base64 c.base64

This appears to be the source that is tripping it up.

/* Nothing to do on bigendian systems. */
#if ( __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ )
    return( x );
#endif /* __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ */

#if ( __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ )

/* For GCC and Clang, have builtins for byte swapping. */
#if defined(__GNUC__) && defined(__GNUC_PREREQ)
#if __GNUC_PREREQ(4,3)
#define have_bswap
#endif
#endif

#if defined(__clang__) && defined(__has_builtin)
#if __has_builtin(__builtin_bswap32)  &&                 \
    __has_builtin(__builtin_bswap64)
#define have_bswap
#endif
#endif

Ah good. It looks like a compiler bug. I hadn’t realised that my compiler version was so old. Does the d in DDE28d signify a test version? The ROOL shop doesn’t indicate what the current version is.

‘d’ is the patch version – there have been a few free patches/updates released for DDE28 since the initial release. So if you were to buy/upgrade now, it should be DDE28d you receive.

I have tried the build with DDE27, cc vsn 5.72 [07 Apr 2016], it does fall over as originally described.

I can confirm that a new version of the compiler does work correctly.

I’m having problems with !builder though. The first time I run it after boot it gives the error ‘amu not found’ after acknowledging the error it starts up. If I quit !builder and restart it works ok. Removing the build variables with *unset build* causes !builder to start up with an error again. It appears that !builder is trying to access tools before build$path is set up.

Do you see that problem?

Do you see that problem?

This is what happens here.

A simple work around is to increase the next slot, 1024k suffices here. This comes from a comment I saw somehere in git.

HTH.

I normally run with a 4096k next slot so never got the memory error. I get the gawk error if AcornC/C++ setpaths has been seen so presumably in that case builder sees amu and fails at the next tool it can’t find.

Hmm. A build today completed without any other error with a 1024k next slot. I am not seeing ‘amu not found’. Hmm.

I needed to modify RiscOS.Env.!Common in the distribution. The Build$path macro needs moving to after tool$Dir is set and before the amu test like this:

|
set Build$Dir      <Obey$Dir>.^
/<Build$Dir>.Library.build.canonical Build$Dir
set Tools$Dir      <Build$Dir>.Library
setmacro Build$Path     <Tools$Dir>.Acorn.,<Tools$Dir>.Build.,<Tools$Dir>.Unix.,<Tools$Dir>.Misc.,<Tools$Dir>.,<Tools$Dir>.DrSmiths.Utilities.

so that the fixed amu test can access the tools

Did you you use git by any chance – I didn’t – the file may be different.

Forget that it made no difference and looking more at the file I can’t see why it would.

This might be worth a look. The amu check is removed. It is only two files that can be downloaded individually. I did not use them for these DiscDev test builds as tweaking the next slot works.

P.S. I have now done a further build using those two files, Env.!Common and Env.Makefile, it worked without needing to increase the next slot and without any errors.

I was nearly right.

build$path and run$path need to be set before Env.Makefile is run, not after as shown below, as it calls amu and gawk without a path.

env.!common snippet:

/<Tools$Dir>.Acorn.amu -f <Build$Dir>.Env.Makefile FIXED=yes find-amu-version
set alias$amu_machine amu MACHINE=<Machine> LOCALE=<Locale> SYSTEM=<System> BUILD=<Build> UserIF=<UserIF> APCS=<APCS> %%*0
if "<BuildSys$AMU$Fixed>"="yes" Then set alias$amu_machine amu -E %%*0
|

| This is setup so this can be run multiple times without extending Run$Path
if "<Build$Setup>" = "" then set Run$Path Build:,Apps:,<Run$Path>
setmacro Build$Path     <Tools$Dir>.Acorn.,<Tools$Dir>.Build.,<Tools$Dir>.Unix.,<Tools$Dir>.Misc.,<Tools$Dir>.,<Tools$Dir>.DrSmiths.Utilities.

env.Makefile snippet:

# Determine whether the macro processor in amu works or not
FIXED = no
find-amu-version:
	@set BuildSys$AMU$Fixed ${FIXED}
	@amu -help { > <Wimp$ScrapDir>.amu }
	@GNU.gawk "NR==2 { print \"Set AMU$Version \"  $3*100 }" { < <Wimp$ScrapDir>.amu > Pipe:$.amu }
	@remove <Wimp$ScrapDir>.amu
	@obey Pipe:$.amu
	@seteval AMU$HasWorkingWildcard <AMU$Version> > 532