One thing I noticed is that the .px4 firmware generated when you execute make px4-v2 is not the same ( in binary comparison) even when using the same source code!
Followed instructions in this link to make the firmware.
When I follow the below sequence
Do ‘make px4-clean’ and then ‘make px4-v2’, firmware generated ( lets call this firmware1)
I do a ‘make px4-v2’ immediately after step1 without any changes, firmware generated( lets call this firmware2)
I do a ‘make px4-v2’ immediately after step2 without any changes, firmware generated( lets call this firmware3)
What I observed, when I do a compare of these firmwares via the tool beyond compare is that firmware1 is different from firmware2 but firmware2 is same as firmware3 ( I am not talking about differences in compile time etc. which is embedded in the firmware but the image itself)
Why is this? Can anyone throw some light on the build process of ‘make px4-v2’ in this regard? ( Or direct me to any article?)
Source code version used - Copter 3.6-dev ( made couple of code changes for logging some extra variables)
Environment - Ubuntu 16.4.2 LTS
Internet on the computer was switched off during the make just to ensure there is no git submodule update or anything happening.
Also is there a way to ensure that if me and my friend use the same source code ( on different computers), the firmware we generate is going to be exactly the same?
Any help/comments on this would be appreciated.
Thanks
As unintuitive as it may sound what you are seeing is normal. The reason for this is that compilers are not necessarily deterministic, basically due to possible optimization depending on current state of the machine you are using when compiling (e.g. amount of memory available), generation of unique names, random seeds, etc …
Also is there a way to ensure that if me and my friend use the same source code ( on different computers), the firmware we generate is going to be exactly the same?_
In terms of functionality, they will behave exactly the same. But binaries will probably differ bitwise for the reasons above.
Btw, had fun replicating what you did, 4 times. Sizes of all 4 ARM executables:
843605, 843229, 843229, 843561. Besides “build_time” in header, all actual binary images were different. But no worries, same exact functionality
Thanks a lot for looking into this and for the explanation!
Personally I feel that since arudupilot is kind of a “mission critical” software, and since a lot of people are making use of this software (kudos to developers for doing such a wonderful job) we should (at least in a long term plan) probably look into making the compilation ( or using a compiler) more deterministic in nature.
