Hi all,
I’m wondering if anyone has done work on getting reproducible builds under catkin? See:
https://wiki.debian.org/ReproducibleBuilds/Howto
I care less about bit-for-bit identical deb files; my interest is primarily in getting binaries from build to build whose buildid is stable (until the underlying sources mutate, of course). I’m still studying the problem, but I seem to get arbitrary mutations all over the system, including pretty low level pieces, like libroscpp.so.
Given roscpp’s dependence on boost::bind and its use of anonymous namespaces for symbols like _1, I’m wondering if that’s a source of non-determinism. Does anyone have experience with integrating -frandom-seed into a CMake project? What’s a possible strategy for doing that “at scale”?
2 Likes
Hi Mike,
I got all of ROS in Debian to build reproducible, see column Rep here:
https://qa.debian.org/developer.php?login=jspricke
We are using standard cmake and debhelper. Have a look into the build
logs, if you want to see the build details.
Cheers Jochen
Oh cool, thanks a lot for the pointer! I had assumed the upstream Debian packaging effort was using conventional bloom/GBP workflow— didn’t realise it was its own thing. Nice work.
My scenario is similarly building via a dsc, but not using the standard toolchain at all; I build a big chunk of packages all at once, in parallel, using catkin_tools. See for an example the rules file from this demonstration repo: https://github.com/mikepurvis/ros-bundling/blob/master/debian/rules
So anyway yes, looking at your log for ros-ros-comm, an individual line is like:
cd /«PKGBUILDDIR»/build/clients/roscpp && /usr/bin/c++ -DROSCONSOLE_BACKEND_LOG4CXX -DROS_PACKAGE_NAME=\"roscpp\" -Droscpp_EXPORTS -I/«PKGBUILDDIR»/build/devel/include -I/«PKGBUILDDIR»/clients/roscpp/include -I/«PKGBUILDDIR»/build/devel/include/ros -I/«PKGBUILDDIR»/tools/rosconsole/include -I/«PKGBUILDDIR»/utilities/xmlrpcpp/include -I/«PKGBUILDDIR»/build/clients/roscpp -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -Wall -Wextra -o CMakeFiles/roscpp.dir/src/libros/poll_set.cpp.o -c /«PKGBUILDDIR»/clients/roscpp/src/libros/poll_set.cpp
I’ve already normalized my buildpath, so debug-prefix-map shouldn’t matter. Nothing else here stands out to me as being the thing, unless it’s PIC/PIE that does it. Do you happen to know? The other thing working against me I suppose is that all this is on Trusty, with GCC 4.8.2. Perhaps some stuff has changed in GCC 5/6 that makes reproducibility the default? I can make my build pull in a newer compiler if I have to, but I’d prefer not to bother unless that’s likely to be the issue.
I’ve already normalized my buildpath, so debug-prefix-map shouldn’t matter. Nothing else here stands out to me as being the thing, unless it’s PIC/PIE that does it. Do you happen to know? The other thing working against me I suppose is that all this is on Trusty, with GCC 4.8.2. Perhaps some stuff has changed in GCC 5/6 that makes reproducibility the default? I can make my build pull in a newer compiler if I have to, but I’d prefer not to bother unless that’s likely to be the issue.
Using gcc (and debhelper I guess) from Trusty could very well be the
culprit. Debian efforts started end 2014 (after the release of Trusty)
and with a lot of patches. They have a lot of information on their
project page about it:
https://wiki.debian.org/ReproducibleBuilds
Okay, looks like the key is indeed the -fPIC flag. Thanks!