Bug#1024638: opencv: embeds build path in Python extension
Victor Westerhuis
victor at westerhu.is
Wed Feb 1 00:11:48 GMT 2023
Vagrant Cascadian <vagrant at reproducible-builds.org> schreef op 22 november 2022 19:56:07 CET:
>On 2022-11-22, Victor Westerhuis wrote:
>> Stripping the rpath from the Python extension makes its BuildId
>> reproducible. The extension still works and both arch:all and arch:any
>> builds succeed locally.
>...
>> diff --git a/debian/rules b/debian/rules
>> index b4d654102..6bd845023 100755
>> --- a/debian/rules
>> +++ b/debian/rules
>> @@ -151,6 +151,7 @@ override_dh_auto_configure:
>> -- --name=opencv --system=custom --configure-args "\
>> dh_auto_configure -S cmake -D modules/python -B {build_dir} -- \
>> -GNinja \
>> + -DCMAKE_SKIP_RPATH=ON \
>> -DOpenCV_BINARY_DIR=$(CURDIR)/$(BUILDDIR) \
>> -DOPENCV_PYTHON_STANDALONE_INSTALL_PATH={install_dir} \
>> -DOPENCV_SKIP_PYTHON_LOADER=ON \
>
>I would recommend using -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON instead of
>-DCMAKE_SKIP_RPATH=ON.
Unfortunately the Python modules are built as a separate module via a separate Cmake invocation, so this has not worked. The rpaths passed to the linker of the Python libraries are absolute build paths, so they are not reproducible.
>
>This is the default behavior with (the currently experimental) debhelper
>compat level 14. A little more detail on the issue is available here:
>
> https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
>
>The main advantage of CMAKE_BUILD_RPATH_USE_ORIGIN is it is more likely
>to work with test suites that depend on the full path.
OpenCV does not ship tests for its Python module, so this is not an issue.
>
>live well,
> vagrant
Control: reopen -1
I would suggest to change the d/rules files to my original proposal.
--
Groet, Regards,
Victor Westerhuis
More information about the debian-science-maintainers
mailing list