[Debian-med-packaging] Bug#1010276: Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available

[Andreas Tille]

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