Different output binaries for Windows and Linux

Advanced Solutions
#1

One of the reasons we chose PlatformIO was that it was cross-platform and cross-IDE.
We have now found that it is not host-OS agnostic.
During a test, we found that the binaries produced when building on Windows 10, differed from the binaries built on Linux, this is even though we have specified platform = ststm32@8.1.0 which I believe should “lock” packages.

It was found that the versions of gccnonearmeabi used were different:
Windows: 1.80201.190214
Linux: 1.80201.181220

We thought this issue could be solved by setting platform_packages = toolchain-gccarmnoneeabi@1.80201.181220 but to no avail, as the Windows build does not recognize this version.
This is due to the fact that the binaries on bintray are built from different versions of gcc for different OSs, so 1.80201.181220 is not available for Windows.

Can this be remedied in some way? Either by aligning the versions available on bintray, or possibly to allow for choosing the Zephyr compiler (we use the Zephyr framework).

#2

They’re not different. They’re both GCC 8.2.1 (80201). The last digits are just the datecodes when they were added (2019-02-12) – it uses the same underlying compiler version.

1 Like
#3

Then why are the binaries different?

#4

How exactly do you see that they’re different?

#5

The problem happened when the code simply did not run on the target when built on Windows, this sparked the investigation.
A simple ls -l also shows a size difference of 8 bytes between the two binaries, additionally diff also reports the files are different.
Visually inspecting the bytes of the binaries using colordiff -y <(xxd foo1.bin) <(xxd foo2.bin) also shows multiple bits which are not equal.

#6

I have also tested with the Blink example an empty main (using framework Zephyr), using ststm32@8.1.0, still diff tells me the files are different.
e.g. (Windows left, Linux right)
image

#7

And that is with the Blinky example? And which board? Full platformio.ini?

#8

I have not tested if an empty application (sorry, did not use blinky, just empty main) runs on target, but the issue still remains that the binaries are different, when compiled under Windows vs Linux, as shown in the picture.
The platformio.ini is as follows.

[env:nucleo_h743zi]
platform = ststm32@8.1.0
board = nucleo_h743zi
framework = zephyr

Main file is

#include <zephyr.h>
void main(void)
{
}
#9

Just want to say that I’m having the same issue on ESP32 with Platformio 5.1.1.

Linux and Windows files are different, and I have the issue with some part of the code execution on Windows.

Regards.
Milan

#10

Encountered this issue on Windows and my CI environment (Linux) and fixed it by stripping symbols in a post-action script:

strip_tool = env['CC'].replace("gcc", "strip")
env.AddPostAction(
    "$BUILD_DIR/firmware.elf",
    env.VerboseAction(" ".join([
        strip_tool, "--strip-unneeded", "$BUILD_DIR/firmware.elf"
    ]), "Stripping symbols...")
)

The issue I faced was that linking against libgcc was adding symbols that are platform-dependent, e.g.:

  • Windows: /home/jenkins-mingw32/workspace/avr-gcc-staging/label/Ubuntu14.04x64-mingw32/gcc-build/avr/avr6/libgcc
  • Linux: /home/jenkins/workspace/avr-gcc-staging/label/debian7-x86_64/gcc-build/avr/avr6/libgcc

Hope this helps!