Hi Étienne, Am Sun, May 01, 2022 at 10:50:16AM +0200 schrieb Étienne Mollier: > I'm still looking up this issue, but I wrap up a status to clear > my mind. > > To me, the main topic of the bug is the reproducibility issue[1] > observed on i386, but other architectures may be affected. The > difference is of one *.a file, and after looking up the d/rules > file, this seems to be caused by the assumption that find sorts > in a predictable way in the recipe below, which is not the case: > > override_dh_install: > dh_install > mv `find .libs -name "libparasail*.a" | head -n1` > debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libparasail.a > d-shlibmove --commit \ > --multiarch \ > --devunversioned \ > --exclude-la \ > --movedev debian/tmp/usr/include usr \ > --movedev "debian/tmp/usr/lib/*/pkgconfig/*.pc" > usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig \ > debian/tmp/usr/lib/*/*.so > rm debian/libparasail-dev/usr/lib/$(DEB_HOST_MULTIARCH)/libparasail.a > dh_install -p libparasail-dev .libs/*.a usr/lib/$(DEB_HOST_MULTIARCH) > find debian -name "lib*.la" -delete > > I would welcome thoughts on the intent of this part of the code, > because I'm not sure which .a is the one that is supposed to be > selected. If the content is not that important, then maybe it > is just a matter of putting a `sort` between the `find` and the > `head` in the `mv` command.
Thanks for having a look into this. I think it does not matter much wgat file is copied here since it is removed afterwadrs inside the rm statement. It was just a trick to make d-shlibmove not complaining about a missing libparasail.a file which is provided that way. Later in the `dh_install -p` statement simply all *.a files are copied by keeping their names whatever it might be. > [1]: > https://tests.reproducible-builds.org/debian/dbdtxt/unstable/i386/parasail_2.5+dfsg-3.diffoscope.txt.gz > > Mattia Rizzolo, on 2022-04-27: > > In fact, it seems that depending on the type of CPU it builds on, > > sometimes there are slightly different files. For example, on an i386 > > system: > > - usr/lib/i386-linux-gnu/libparasail_novec_table.a > > - usr/lib/i386-linux-gnu/libparasail_sse41_rowcol.a > > - usr/lib/i386-linux-gnu/libparasail_avx2_table.a > > or in an amrhf system: > > - usr/lib/arm-linux-gnueabihf/libparasail_novec.a > > - usr/lib/arm-linux-gnueabihf/libparasail_novec_rowcol.a > > sometimes are there or not. > > While I agree it is an error to build binaries to target > specific CPU when doing large scale distribution, in the case of > parasail, this is actually normal. Upstream implements run time > CPU detection to avoid baseline violation on older CPU. After > building the package with avx2 support, I could run the > autopkgtest suite on a generic x86_64 virtual machine (no avx2, > no sse4) without an illegal instruction crash. From the > README.md file in parasail source code: > > >> parasail uses CPU dispatching at runtime to correctly select > >> the appropriate implementation for the highest level of > >> instruction set supported. > > Interestingly, while trying to understand the variability of > build result, I noticed that we were missing builds for avx512 > instruction set, which seems to stem from ./configure failure to > recognize the option due to warnings occurring in the sample > code when -Wall build option is in use. That's probably worth > forwarding upstream. Thanks for noticing this. > > Furthermore, I notice that amongst the i386 build, there are files such > > as > > - usr/lib/i386-linux-gnu/libparasail_sse2.a > > - usr/lib/i386-linux-gnu/libparasail_sse41.a > > that makes me wonder if the program is unconditially using SSE > > instructions on i386, that would be a baseline violation; but since I > > haven't verified if those features are used unconditially I'm not filing > > this report about this, however please do check. > > On the i386 build, I also see avx2 builds, and I would tend to > think those extensions were never implemented on i386, so I > guess it wouldn't hurt, and would reduce resource consumption on > build machines in the process, that these variants are actually > not built. It should be a matter of just passing --disable-avx2 > and similar to the configure step when targeting i386 host > architecture. ACK. > So I identified three todo items: > 1. address reproducibility issue likely caused by find|head; As I tried to explain this theory is not really plausible. > 2. fix avx512 support for amd64 architecture; This would be great. > 3. disable execessive build artifacts for i386 architecture. My guess is this will rather lead to solving the reproducibly issue. > Thanks Mattia for your work on the reproducible build effort, > these issues may not have been caught otherwise! +1 > Have a nice day, :) +1 Kind regards Andreas. -- http://fam-tille.de