Firmware build for ESPRUINOWIFI fails make: *** [libs/graphics/lcd_arraybuffer.o] Error 1 'for' loop only allowed in C99 or C11 mode

Sun 2021.10.24

Firmware build for ESPRUINOWIFI fails make: *** [libs/graphics/lcd_arraybuffer.o] Error 1

Two weeks ago I was able to build .elf and .hex files using the steps clarified by @Gordon

post #12 and #14    nRF52840DK build error: src/jslex.o make

I used this sequence:

make clean
source scripts/provision.sh ESPRUINOWIFI
make clean make
make clean && BOARD=ESPRUINOWIFI RELEASE=1 make

Which ran fine:

rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/espruino$ make clean
Cleaning targets
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/espruino$ source scripts/provision.sh ESPRUINOWIFI
Provision BOARDNAME = ESPRUINOWIFI
Provision FAMILY = STM32F4
===== NRF52
===== ARM
arm-none-eabi-gcc installed
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/espruino$ make clean make
make: Nothing to be done for 'make'.
Cleaning targets
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/espruino$ make clean && BOARD=ESPRUINOWIFI RELEASE=1 make
Cleaning targets
CC /mnt/c/Users/robin/espruino/targetlibs/stm32f4/lib/startup_stm32f401xx.o
Generating platform configs
Generating pin info
Generating JS wrappers
WRAPPERSOURCES = src/jswrap_array.c src/jswrap_arraybuffer.c src/jswrap_dataview.c src/jswrap_date.c src/jswrap_e

. . .


and on and on to completion

I have not used my PC other than for email and one Windows10 update behind the scenes did reboot my laptop this past Friday.

2021-10 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB5006670)
Successfully installed on 10/19/2021

I haven't fetched (intentionally by me) or cloned from github, I haven't made any file modifications to the make, or board .py files either. I just started this morning with the intent to build continuing where I left off, but now get htis unique new error:

libs/graphics/lcd_arraybuffer.c:222:9: error: 'for' loop initial declarations are only allowed in C99 or C11 mode         for (int i=0;i<gfx->data.bpp;i+=8)
         ^
Makefile:803: recipe for target 'libs/graphics/lcd_arraybuffer.o' failed
make: *** [libs/graphics/lcd_arraybuffer.o] Error 1
make: *** wait: No child processes.  Stop.
rgc@DESKTOP-R7T0VUC:/mnt/c/Users/robin/espruino$

In the mean time I re-reading:

nRF52840DK build error: src/jslex.o make

and

https://github.com/espruino/Espruino/blob/master/README_Building.md#for-stm32-boards-incl-espruino-board

I haven't changed any recipe within the make file, I haven't made any mods to the LCD libs, or any lib file for that matter.

Also repeatable for other boards. I verified all .o files are removed from the \gen folder prior to the final 4th make clean build step. I stopped all virus background checking. See full console upload. . . . too large to embed here

1 Attachment

• uploadlcd_arraybufferFailed.txt

Sun 2021.10.24 11:58am CST

S.W.A.G. here, could this be related to the layout issue here as the errors occur similarly to LCD Graphics array buffer output as described at:

Layout Library Not Working

or is this just a stange co-inky-dink?

Been at it another two hours even trying @fanoush export path statement which two weeks ago seemed to work. but still consistent:

libs/graphics/lcd_arraybuffer.c:222:9: error: 'for' loop initial declarations are only allowed in C99 or C11 mode 
         for (int i=0;i<gfx->data.bpp;i+=8)

Seems identical to this post years ago: (but using Ubuntu directly)

Compiling errors on Ubuntu 16.04

No confirmed solution there however.

Long day at this; running out of daylight . . .

Trying these suggestions:

https://stackoverflow.com/questions/38405260/difference-between-c99-and-c11
https://es.stackoverflow.com/questions/73761/for-loop-initial-declarations-are-only-allowed-in-c99-or-c11-mode/73764
https://stackoverflow.com/questions/40303668/how-do-i-fix-for-loop-initial-declaration-used-outside-c99-mode-gcc-error
https://stackoverflow.com/questions/15870567/how-to-compile-a-c-project-in-c99-mode

Looks suspiciously like you've installed the wrong compiler version? If you don't have anything installed then provision.sh should do it for you automatically.

So apt get remove arm-none-eabi-gcc I think? Then run provision again.

Mon 2021.10.25

'Looks suspiciously like you've installed the wrong compiler version?'

That should have been stated: 'Looks suspiciously like the wrong compiler version is installed',

   as .  .  .

I've not done anything other than follow the instructions on GitHub.

That said, it is likely that you've hit on something. (see following post)

What version of arm-none-eabi-gcc -v is supposed to be installed, or is installed on your system?

---cont

Before I start making changes;

'So apt get remove arm-none-eabi-gcc I think? Then run provision again.'
'If you don't have anything installed then provision.sh should do it for you automatically.'

If I grasp the intent of the above, the provision script should only install gcc if gcc was not present before the script is run. Am I understanding that correctly?

Under the assumption that is the correct understanding, I Googled a bunch and found this, mildly related tid-bit.

Where is GCC ARM none Eabi installed?
Installing the ARM Toolchain for Windows

Download and run the installer to install arm-none-eabi-gcc and arm-none-eabi-gdb. Select the default destination folder: C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2020-q4-major.

I did not follow those instructions, but did some poking around and along with:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882

My version is subtlety different than that one mentioned from a year ago, and now

make what I believe to be an astute observation.

History:
Remember, I cloned the repository following the Readme build instructions over two years ago, which after a few weekends was able to get running. I build one .hex file and flashed it just to gain a bit of confidence.

Never touched that install, other than to look at the .c .h source for the Neopixel functions and where they were located.

One month ago, I made an attempt to compile the nRF52 stuff to see if a build was possible, knowing that many changes had occurred and likely would fail. It did.

Made a backup of all the old cloned files there, and followed the step-by-step process that we did two years ago, starting with cloning the current Espruino repoistory.

Now for the astute observation:
Should my understanding that the provision script only installs when a version of gcc is not present, then it is quite possible that the old gcc content is still there. It ran two years ago, but fails now.

What should the current gcc version be?

Should my understanding that the provision script only installs when a version of gcc is not present, then it is quite possible that the old gcc content is still there. It ran two years ago, but fails now.

Yes, that's entirely possible. While I try and document what's needed in https://github.com/espruino/Espruino/blob/master/README_Building.md I can't document every eventuality - specifically that something has been set up on the computer beforehand that wouldn't normally be set up.

The provision script does not permanently install GCC - it does it only for that session - so this exact thing does not happen. It is however possible that at some point you followed some steps you found on the forum or googled that would have permanently installed the compiler.

I can't remember the specific version used but it's easy enough to find in scripts/provision.sh

Wed 2021.10.27

'While I try and document what's needed in ... I can't document every eventuality'

I'm totally with you here. Upon weeding through all the new terms, what is there is nicely laid out and well documented.

A month ago when I first discovered the previous (2 yrs ago) install wasn't going to cooperate, I had this grandious idea to document step-by-step in order to create a nice pictorial tutorial for Win10 machines.

Four weekends of fun and surprises has exposed the reality that there are too many permutations and combinations of the individuals parts that are required to allow that incredibly complex process to function 100% of the time.

And as you have pointed out, every eventuality is just too complex to create a single tutorial. Each user will have it's own nuances and installed program structure, along with an unknown level of updates that may or may not be current and at the level needed for the scripts to run. The only real way is exactly how I'm floundering right now, just keep asking questions to resolve each hiccup along the way. Painful, . . . and an incredibly steep learning curve.

As your nicely laid out step-by-step process is the simple basic process that will work when understood, it is in fact the better way to get individuals started.

Wed 2021.10.27

'The provision script does not permanently install GCC'

This is a good tid-bit of detail related to my specific issue.

I got as far as openning the provision script and found

        if [ ! -d "gcc-arm-none-eabi-8-2018-q4-major" ]; then
          curl -Ls https://github.com/espruino/EspruinoBuildTools/raw/master/arm/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 | tar xfj - --no-same-owner

and have run out of time to dig deeper.

My plan for the weekend is to run the removal command suggestion provided in post #6 and determine if progress can be made.

Sun 2021.10.31

'It is however possible that at some point you followed some steps you found on the forum or googled that would have permanently installed the compiler.'

Thanks @Gordon, that worked.

Had I not taken extensive notes during this recent VSCode revitalization, it is unlikely I would have discoverd how gcc gets installed.

The day I re-cloned the Espruino repository, I upgraded nRFConnect which forced the install of the SDK15 for the nRF52 chips, and also upgraded make, nrfutil, and esptool to get the latest versions.

During the process of upgrading the above, (maybe during some future install - which one)

this warning popped up:

'The program 'arm-none-eabi-gdb' is currently not installed. You can install it by typing:
sudo apt install gdb-arm-none-eabi'

I followed the instructions:

sudo apt install gdb-arm-none-eabi

which unpacks and installs (around thirty lines in)

Get:2 http://archive.ubuntu.com/ubuntu xenial/universe amd64 gcc-arm-none-eabi amd64 15:4.9.3+svn231177-1 [17.3 MB]
8% [2 gcc-arm-none-eabi 1,871 kB/17.3 MB 11%]

So, future firmware builders, beware when upgrading nRFConnect to build for nRF52