The xPack GNU Arm Embedded GCC

[ilg-ul]

Please note that the GNU MCU Eclipse ARM Embedded GCC was rebranded as The xPack GNU Arm Embedded GCC and was migrated to the xPack project:

https://xpack.github.io/arm-none-eabi-gcc/

Since you downloaded the binaries there were a few more releases, see:

https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases

[fpistm]

Hi @ilg-ul
I saw that and planned to update.
Thanks for your great work 👍
Note that I do not update each time a new release is available and I subscribe to watch new relese😉

[ilg-ul]

There will be a new release following Arm's 9.x release, but I have no ETA, it might take a few weeks. Anyway I guess the latest 8.3 is stable and you should have no problems with it.

Just please be sure you update the public link to point to the new locations.

Good luck!

[fpistm]

Just please be sure you update the public link to point to the new locations

Of course I will linked to the new location

[ilg-ul]

Just curious, isn't there any way to customise the install step, so that you can use the binaries as they result from my build script, without having to repack them? To me this repack seems a pain in the rear.

[fpistm]

Arduino simply extract the archive, this is not an install.

[ilg-ul]

And there is nothing to do to avoid repacking the binaries and use them as is?

[fpistm]

@ilg-ul
I will have to check what can be done.

[ilg-ul]

Although I accept that I have no experience with the Arduino environment, I offer myself to help you find a solution.

Can you point to a page in the Arduino environment, handling the toolchain?

[fpistm]

Arduno simply download the package (archive) provided in an JSON file for the dedicated host:
https://github.com/stm32duino/BoardManagerFiles/blob/637d6fdc01436dd5681666a0a1930f969b429bb0/STM32/package_stm_index.json#L902-L934

When extracted it splits the name and version to set its folder structure:
gcc-arm-none-eabi-8.2.1-1.7/
becomes:
gcc-arm-none-eabi/8.2.1-1.7/

In fact, when I repack, I simply extract the xpack, move the toolchain in a directory with the desired name then repack.
Ex:
extract:
xpack-arm-none-eabi-gcc-8.3.1-1.3-linux-x32.tgz

rename xPack/ARM\ Embedded\ GCC/8.3.1-1.3/ to gcc-arm-none-eabi-8.3.1-1.3
then gcc-arm-none-eabi-8.3.1-1.3 redo the archive named gcc-arm-none-eabi-8.3.1-1.3-windows.tar.bz2

When done for all desired target (win32, linx 32/64 and mac), I do a release and launch a makefile to generate the new JSON entry:
https://github.com/stm32duino/arm-none-eabi-gcc/blob/master/Makefile

[ilg-ul]

so, correct me if I'm wrong, but it seems that all you need to do is to rename some folders.

why not update the code that installs the toolchain, to do the rename after unarchiving the original packages? you could extend the JSON with a new definition to define the rename.

if you are happy with repacking, you can also consider automating the process, you can get the xPack definition JSON (https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/blob/xpack/package.json), download the associated binaries, convert them, etc.

my 'xpm' tool does something similar, it downloads the archive, skips a number of folders and extracts the content in a folder named .content in the xPack folder.

[fpistm]

why not update the code that installs the toolchain

This is handled by Arduino IDE, so not my hands 😉

if you are happy with repacking, you can also consider automating the process, you can get the xPack definition JSON (https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/blob/xpack/package.json), download the associated binaries, convert them, etc.

my 'xpm' tool does something similar, it downloads the archive, skips a number of folders and extracts the content in a folder named .content in the xPack folder.

Probably this can do the job but I don't know or never use that.

[fpistm]

FYI:
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.6.x-package_index.json-format-specification#tools-definitions

[ilg-ul]

aha. where does it define that the executables are in a folder named bin and not somewhere else?

[fpistm]

https://github.com/stm32duino/Arduino_Core_STM32/blob/ad09a48db2d4c6a05491f9be91ef095580fca5f6/platform.txt#L20

[ilg-ul]

one possible solution would be to edit that file and add the extra folder levels there. would it be acceptable?

but this issue opened another possibility: for future releases I'm considering to simply shorten the path and remove the extra folder levels, they are there only for historical reasons, (by the time when there was no xPack manager to handle multiple versions it was easier to simply have them in the archive), I guess now they can be removed, xpm automatically creates the versioned folders.

[fpistm]

This will require some tests because I guess the main issue is how this will be extracted by Arduino IDE.

[ilg-ul]

right.

but assuming the Arduino IDE does not mess it, adding the extra path in that file would be enough for the current archive content?

if so, when a new xPack release with the short path will be available you'll simply have to edit the file back to the initial /bin and that should be it.

[ilg-ul]

I took a look at my archives and compared to those produced by Arm, and my current proposal is to linearise the path, so instead of xPacks/arm-none-eabi-gcc/8.3.1-1.3/ to use xpacks-arm-none-eabi-gcc-8.3.1-1.3.

does this solution better matches your needs? in other words, if I do this, can you directly point your json to the xPack binaries at https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases, so you don't have to do any repacking, renaming, republishing, etc?

[fpistm]

Hi @ilg-ul

So as you saw I've made some test.
I've tested the current archive format and as I've expected this does not work and have the message:

 Archive format not supported.
java.lang.RuntimeException: java.io.IOException: Archive format not supported.
	at cc.arduino.contributions.packages.ui.ContributionManagerUI.lambda$onInstallPressed$2(ContributionManagerUI.java:175)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Archive format not supported.
	at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:107)
	at cc.arduino.utils.ArchiveExtractor.extract(ArchiveExtractor.java:82)
	at cc.arduino.contributions.packages.ContributionInstaller.install(ContributionInstaller.java:146)
	at cc.arduino.contributions.packages.ui.ContributionManagerUI.lambda$onInstallPressed$2(ContributionManagerUI.java:172)
	... 1 more

So based on your proposal, I've repacked the 8.3.1-1.3:
instead of
xPacks/arm-none-eabi-gcc/8.3.1-1.3/
use
xpacks-arm-none-eabi-gcc-8.3.1-1.3/

then in the JSON I've change the name from:

-              "name": "arm-none-eabi-gcc",
+              "name": "xpack-arm-none-eabi-gcc",

and add the correct tools description.
So this works fine. One other think I have tested is to update a previous install to check if the name change works.
Finally, I only have to update the path in the platform.txt.

- compiler.path={runtime.tools.arm-none-eabi-gcc-8.3.1-1.3.path}/bin/
+ compiler.path={runtime.tools.xpack-arm-none-eabi-gcc-8.2.1-1.7.path}/bin/

[ilg-ul]

Ok, thank you for testing, it seems promising.

I'll make a pre-release with the new linearised folder and give you the chance to test it.

[fpistm]

I'll make a pre-release with the new linearised folder and give you the chance to test it.

Yes, that should be fine. Thanks a lot.

[ilg-ul]

Please test the binaries and the sha sums available from the pre-pre-release site:

https://github.com/xpack-dev-tools/pre-releases/releases/tag/v1.0

If you confirm that you can use them directly in your json I'll run the macOS build too and prepare the proper release.

[ilg-ul]

For the windows zip I used the same folder name, perhaps you should test it too.

The macOS one will be the same, but, from my experience, if Linux and Windows are fine, most probably macOS is fine too.

[fpistm]

@ilg-ul
Thanks a lot
I've tested under windows and linux (x64).
On Linux this not work because Arduino IDE does not recognized ".tgz" while "tar.gz" is recognized. 🙄
So renaming to "tar.gz" this is OK and on windows this is also OK.

From my point of view all is OK except the ".tgz" extension.
For MAC, this should be OK as well.

I guess you want kept xpack in the name ?

[ilg-ul]

So renaming .tgz to .tar.gz would do it for Linux and the existing .zip were fine on Windows, right?

I added the .tar.gz files in the pre-pre-release for you to do a final test.

I guess you want kept xpack in the name ?

Well, it is kind of a brand, so yes, I would prefer to keep this in the names, and I would prefer you not repacking the archives and using the original URLs, once we solve all technical issues.

[fpistm]

Yes .zip is fine for windows.
Not that for mac this should be also .tar.gz.

[ilg-ul]

On Linux this not work because Arduino IDE does not recognized ".tgz" while "tar.gz" is recognized.

If I were you, I would suggest you make an enhancement request to the Arduino IDE project, the change to also support .tgz is minimal and is useful, not all toolchain maintainers will agree to rename their archives as easily.

[ilg-ul]

Not that for mac this should be also .tar.gz.

Yes, all non-windows will be tar.gz.

Were the new renamed linux archives directly accepted from the GitHub pre-release site?

[fpistm]

Yes this is fine now.
Thanks a lot.

[ilg-ul]

Ok, in this case I'll proceed with the release, and also consider a new release with gcc 9.x.

[ilg-ul]

https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v8.3.1-1.4

The full release will follow soon, together with the 9.x release.

[ilg-ul]

Please confirm after updating your configurations to 8.3.1-1.4 and running some tests, since I had no time to test anything, I relied on the tests I did for 8.3.1-1.3 (same binaries, anyway), but I don't know the specifics of your environment, so better be careful.

I'm running the build scripts for 9.x, they'll be ready in a few hours.

[fpistm]

@ilg-ul
I'm currently testing and deploying: stm32duino/Arduino_Core_STM32#819

Install and build are OK for Mac, Linux and windows.

[ilg-ul]

Great! Thank you for your notice. I'll proceed with the public release, probably today.

[fpistm]

@ilg-ul
Are you confident with the v9.2.1-1.1 release?

I will release the next STM32duino 1.8.0 in the coming weeks so if yes maybe it should be fine to use it directly. As I do a release each 3 month the v9.2.1-1.1 will not be released before.

[ilg-ul]

Are you confident with the v9.2.1-1.1 release?

I don't know what to say, it passed my quick tests on all platforms (building a GNU MCU Eclipse STM32F4 blinky with LTO); right now I'm making the release.

For now it is a go, but I suggest you follow the GitHub project the forum, to be notified in case of problems.

[ilg-ul]

https://xpack.github.io/blog/2019/12/06/arm-none-eabi-gcc-v9-2-1-1-1-released/

[fpistm]

OK
I think I will use it and validate it during my non reg test session.

[ilg-ul]

Good plan.

If you find issues caused by my build, please let me know.

[ilg-ul]

Just curious, since I have no experience with the Arduino IDE: once you update the folder name in the platform.txt to the latest version, can users do some trick to select an older version of the toolchain for some projects?

[fpistm]

Reinstall the previous one or change it manually.
Note that currently this is not officially released.

[ilg-ul]

change it manually.

hmmm.. not very user friendly.

perhaps you should leave the previous folder names as comments in that file.

[fpistm]

hmmm.. not very user friendly

Yes. Not in my hands. Moreover when you update it simply delete all then unpack even if some packages are the same...