`lib/constants.c.in` may contain build path

[jdemel]

For reproducible builds, the following functions are problematic:

https://github.com/gnuradio/volk/blob/07c1952cd642897af70b6f8bbfeee3a14f54f525/lib/constants.c.in#L31-L41

Under some conditions they may contain build paths that are compiled in. @maitbot pointed out that Debian considers this to be a bug now.

[maitbot]

Not quite to the level of bug yet, but a Lintian 'Info' level report.

The Lintian tool does some checking for reproducible build problems: https://lintian.debian.org/tags/file-references-package-build-path

This comes up in building Debian packages, and also in Yocto builds. https://docs.yoctoproject.org/current/test-manual/reproducible-builds.html

Would be good to support reproducible builds. Generating these strings in constants.c for the library seems to stretch the API of a vector compute library.

[maitbot]

--- a/lib/CMakeLists.txt +++ b/lib/CMakeLists.txt @@ -454,6 +454,7 @@

#double escape for windows backslash path separators string(REPLACE "\" "\\" prefix "${prefix}") +string(REPLACE "${CMAKE_SOURCE_DIR}" "$BUILD_DIR" COMPILER_INFO "${COMPILER_INFO}")

configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/constants.c.in

[michaelld]

I come from the MacPorts world of package management, and in MP both CMAKE_SOURCE_DIR and BUILD_DIR will be useless once Volk package is built and installed. Can y'all provide examples of where this topic is an issue & how the PR fixes it? I'm not opposed, just trying to understand better.

[maitbot]

The problem is that volk-config-info was getting --cflags string from Volk CMake COMPILER_INFO - and that contained the build path. Building packages, either .deb or .rpm, via build infrastructure often uses -ffile-prefix-map for gcc or clang in order to keep build paths out of the generated objects. So Debian's volk-config-info --cflags output looked like: /usr/bin/cc::: -g -O2 -ffile-prefix-map=/build/volk-Y4PKF8/volk-2.5.1=. ...

My fix is to replace the actual varying build path in COMPILER_INFO with the literal string $BUILD_DIR that would be the same always. So no, $BUILD_DIR is not interpreted in CMake - it is to be interpreted by the human looking at the output. So after applying the fix, volk-config-info --cflags looks like: /usr/bin/cc::: -g -O2 -ffile-prefix-map=$BUILD_DIR=. ...

So, one problem is solved, but there are still more. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/volk.html

(See also - https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html )

Improvement ideas:

1. Might be best just to remove the entire -ffile-prefix-map argument from COMPILER_INFO. (Since the reproducible-builds folk search for that compiler argument string.)
2. Users might like volk to add a --print-all option, so that volk-config-info acts even more like gnuradio-config-info

[jdemel]

This issue reveals a few interesting points.

According to the "reproducible build bot", we may filter the «-fdebug-prefix-map=${BUILDPATH}=, -ffile-prefix-map=${BUILDPATH}=, and -fmacro-prefix-map=${BUILDPATH}= flags before we fill the template.

The other two reports basically both hint at "cmake_rpath_contains_build_path". We need to check this, but BUILD_RPATH_USE_ORIGIN instead of other rpath functions may fix this. However, this requires, we bump the minimum CMake version to 3.14. Ubuntu 18.04 comes with CMake 3.10. We might be able to work around that though.

Add a --print-all option to volk-config-info is smth I'd like to have too.

[michaelld]

@maitbot great explanation & that makes sense now! Can you please test the following line to see if it works:

string(REPLACE "${CMAKE_SOURCE_DIR}" "\$BUILD_DIR" COMPILER_INFO "${COMPILER_INFO}")

"works" here meaning that there is a literal $BUILD_DIR string in the output -- same as before. My hope is that CMake removes the preceding \ ... I like this version better -- if it works -- as it makes the REPLACE clear that it's a string literal rather than potentially a variable substitution (as what BASH would do).

[michaelld]

I'd love to get the --print-all in place! I use it all the time, since it "just works" for both GR and UHD