How to use a particular specified native toolchain?

PlatformIO Core
1

I’m working on an open-source COVID-19 related project and we’re using PlatformIO.

Our unit tests and various style checks run in “native”. However, this means that different contributors are using different compilers (e.g. those on MacOS end up using clang, those on Linux probably gcc), and these compilers may be yet different from the compiler native to our CI environment. This leads to frustrating experiences where the code compiles or passes style checks for one person, but then fails for another person or on CI.

Is it possible to specify for the “native” environment to use a particular fixed toolchain, e.g. gcc of a certain version? I’m fine even creating a custom “platform” (eg by forking the “native” platform definition), but I don’t know what I should change in there to make it use, say, a particular version of GCC.

1 Like
2

The very definition of the native platforms is it to use the pre-installed compiler on the system, whatever version it may be. That’s also why it doesn’t specify any packages in its platform.json, in contrast to e.g. the platform.json of platform-atmelavr specifying which version of avr-gcc to use.

I think the right approach for that would be to explicitly use the Linux x86_64 and Windows x64 platforms to compile for these platforms. They use GCC 4.8.1 for Linux and GCC-MinGW 5.1.0 respectively. Differing toolchain packages can also be given manually. Though that leads to the problem of not having a properly confined platform for MacOs… Not sure why PlatformIO doesn’t have one, maybe due to licensing / needing XCode / linking against MacOS / an SDK is a problem? I guess for that at least the native platform can be used with a script checking that gcc/clang is at the correct version.

Maybe @ivankravets has some thoughts to share here.

1 Like
3

Hi, I’ve reviewed a bit of your project, congrats by the way.

If I understood correctly you are developing for embedded (AVR, STM32, RPi) but you use native to test, right?. I would have suggested testing directly to the platform, but as you need googletest that would be quite difficult to achieve.

Now, besides what @maxgerhardt said about cross-compiling I think another possibility would be to mix that idea with the pio-remote functionality and remote testing. At least by what the wiki says it should work.

That way, you cross-compile against only one platform Linux ARM and then you can pin-up the version of the compiler. Also pio remote would allow sharing hardware among your team, something that given the situation could help develop your project even faster.

By the way, pio-remote used to be limited for free users, but by what this announcement says, it looks like that changed.

1 Like
4

There is no way to specify a particular version of the native toolchain, PlatformIO will pick up the first GCC that is present in your PATH. I believe you can simply install any required GCC version and modify the PATH variable to it’ll be the first one.

5

@valeros this needs more descriptive resoluion. I have obvious use case - fast GUI development without bare metal. native platform + sdl2 are very convenient for this. Everything is fine, except macOS - it does not support modern cpp features.

Example:

  1. Simple demo. Pure C, all targets fine.
  2. Real project. CPP with ETL and other mess. Native on macOS fails to build. You can see commented out part, with my attempts to force use upgraded toolchain (without success).

Does this need “official” issue in tracker or simple resolution available?

6

@valeros @vit

I know this is an old thread, but I figured out a way to do this. Posting since I found this while looking for a solution.

In platformio.ini:

[env:native_custom_gcc]
platform = native
extra_scripts = pre:modify_path.py
...

Then create a python script modify_path.py in your working directory:

import os 

os.environ["path"] += "C:/path/to/gcc/"

This will let the platformio find gcc in that directory without modifying your system path. If there is another gcc on path you might need to change this a little so this path is added to the beginning instead of the end of your path.