Bug#989399: nauty FTCBFS -- multiple reasons

[Étienne Mollier]

Control: severity -1 important

Greetings everyone,

focusing on the baseline violation aspect…

Helmut Grohne, on 2021-06-02:
> The check does not want to know whether the compiler supports
> popcnt (which could be determined using AC_LINK_IFELSE), but whether the
> CPU does and AC_LINK_IFELSE does not suffice here.
> 
> Unfortunately such opportunistic use of the popcnt instruction violates
> the i386 baseline as it does not include SSE4 at this time. This is a
> serious bug. For Debian, such detection is not appropriate. Debian
> builds must pass --disable-popcnt for any-i386. If the package is deemed
> unusable without such performance optimizations, it should at least
> depend on the appropriate isa-support package likely sse4.2-support.

I have looked up the issue, and rebuilt the package on a popcnt
enabled CPU.  When disassembling the binary packages, I have
seen no traces of *cnt instructions, neither in the libraries,
nor in executable programs.  I do see the following in the build
log, which is quite concerning:

	CC=gcc
	CFLAGS=-g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security
	MORECFLAGS= -mpopcnt -march=native
                    ~~~~~~~~ ~~~~~~~~~~~~~

The -march=native would cause even worse baseline violations
than -mpopcnt, especially if the build occurs on very recent
hardware.  To eliminate both of these entries off the equation,
one would have to configure the build with both --disable-popcnt
and --enable-generic.


Fortunately, note that the MORECFLAGS variable does not make it
down to build options, although it is concatenated into CFLAGS
in makefile.in.  This seems to explain why I don't see baseline
violations in the resulting binary objects on my end.  Still,
standard Debian options are accounted for properly.  I believe
our dh build process never uses upstream's makefile.in template,
but an entirely autoreconf-ed one instead, which does not know
anything of MORECFLAGS, hence the proper result in spite of the
confusing options.

Since the compilation does seem to result in baseline clean
binaries, I dropped the severity to "important".  I prefer not
closing the bug, since I guess plans to adjust the logic for
cross buildability could, eventually, end up injecting such
option properly in the build process.  Of course, please feel
free to readjust the severity, if I missed an important thing in
the problem at play.

Hope this helps,
-- 
Étienne Mollier <etienne.mollier at mailoo.org>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.
-------------- 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-science-maintainers/attachments/20210603/3b508837/attachment.sig>