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
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:
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)
No confirmed solution there however.
Long day at this; running out of daylight . . .
Trying these suggestions:
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.
apt get remove arm-none-eabi-gccI think? Then run provision again.
'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 -vis supposed to be installed, or is installed on your system?
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.
not followthose instructions, but did some poking around and along with:
My version is subtlety different than that one mentioned from a year ago, and now
make what I believe to be an astute observation.
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
notpresent, 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
'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.
'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.
'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
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
I used this sequence:
Which ran fine:
I have not used my PC other than for email and one Windows10 update behind the scenes did reboot my laptop this past Friday.
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:
In the mean time I re-reading:
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.