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

[Étienne Mollier]

Hi Mattia, Hi Nilesh,

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.

[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.

> 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.

So I identified three todo items:
 1. address reproducibility issue likely caused by find|head;
 2. fix avx512 support for amd64 architecture;
 3. disable execessive build artifacts for i386 architecture.

Thanks Mattia for your work on the reproducible build effort,
these issues may not have been caught otherwise!

Have a nice day,  :)
-- 
Étienne Mollier <emollier at emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Vox Tempus - Escape
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20220501/d423cc9b/attachment.sig>