Inconsistent Binary Output When Building STM32CubeIDE Project on Linux and Windows

[NZaugg]

I am facing an issue where the binary output of my STM32CubeIDE project built on Linux and Windows is inconsistent. I have installed STM32CubeIDE Version 1.6.1 and the fixed Toolchain: GNU Tools for STM32 (7-2018-q2-update) on both platforms. Upon comparing the makefiles, I found that they match, but the resulting binaries do not.

Can you suggest steps that I can take to ensure consistent binary output on both platforms? Additionally, which files should I compare to troubleshoot the issue?

[Bob S]

Is the source code tree exactly the same in both versions (including the HAL libraries and startup code)? Did you generate the project from CubeIDE (or CubeMX) on both systems, or copy the source from one to the other? Do the binaries differ in a few bytes or are the significantly different (like - do you ever use __DATE__ or __TIME__ to put the build date/time in the binary)?

[Pavel A.]

or __FILE__

[NZaugg]

@Bob S​, thank you for the answer. Yes, the source code is exactly the same. I copied it from one system to the other. I don't put the build timestamp in the binaries. Furthermore, I also built the same source code on different Windows machines, and the binaries did match.

[Bob S]

So as I asked before - do the binaries differ by a few bytes, or are the significantly different?

Are they the same size?

Have the make file output the compiler version of what is ACTUALLY being used (a dummy target that just calls "gcc -v" or whatever the "get version" switch is).

Look at the build console files and compare them. If you are building in the IDE, the build log files are stored somewhere in the .metadata directory (.metadata/.plugins/org.eclipse.cdt.ui).

[NZaugg]

@Bob S​, sorry for not answering all of your questions. The binaries differ just by a few bytes and they have the same size.

I now compared the actually used compiler version by adding the --version tag to GCC and G++ Miscellaneous Compiler Flags. They do match.

I also compared the .metadata/.plugins/org.eclipse.cdt.ui logs. They do not match because the paths are different. Just the end of the log does match:

text     data      bss      dec      hex   filename

 413732     3576   108948   526256    807b0   ***.elf

[Pavel A.]

@Community member​ do you compare .elf files or .bin ?

[NZaugg]

@Pavel A.​, I compared the .bin file.

[Bob S]

So BIN files are same size and doiffer only in a "few" bytes. FInd the addresses of those bytes that differ, then look in the related MAP file. Or even better, generate a disassembly (.lss ot .list) file. Go to project settings, "C/C++ Build", "Settings", "MCU Post build outputs" and check "generate list file". See what is at those addresses. Realizing that the start of the BIN file is actually 0x08000000 in the listing/map files.

[Pavel A.]

@Community member​ Have you been able to explain the differences?

[Bob S]

Yeah - posting your findings will help others in the same situation.

[NZaugg]

@Pavel A.​ and @Bob S​, thank you for your patience.

Unfortunately, I have not yet been able to solve the problem completely.

But I have found out when the problem occurs. It only occurs when the G++ compiler optimization is set to -O2. If I set it to -O0 for a part of the project, namely a folder with several modules, the build from Windows is the same as the build from Linux. However, I could not figure out in the code what exactly is optimized differently from G++ on Linux than from G++ on Windows.