Subject: bug#51536: openblas builds not reproducible on different x86_64 machines

From: Maxim Cournoyer <[email-masked]>
Date: Fri, 05 Nov 2021 12:38:00 -0400

Hi Efraim!

Efraim Flashner <[email-masked]> writes:

[...]

> I compared our build flags with Debian's¹ (which is also what I often do
> when working on other architectures) and it looks like they have
> DYNAMIC_OLDER=1 and TARGET=GENERIC. From looking through Makefile.system
> it looks like TARGET=GENERIC makes it more portable, and DYNAMIC_OLDER=1
> adds support for some of the older x86_64 sub-architectures.

DYNAMIC_OLDER is probably a good idea (it'll inflate the binary size a
bit), but I doubt it's the culprit here, as my problematic CPU is a
Q6700 from the CORE2 family, already supposed to be covered by
DYNAMIC_ARCH=1 on x86 (c.f. Makefile.system):

--8<---------------cut here---------------start------------->8---
ifeq ($(DYNAMIC_ARCH), 1)
ifeq ($(ARCH), x86)
DYNAMIC_CORE = KATMAI COPPERMINE NORTHWOOD PRESCOTT BANIAS \
	       CORE2 PENRYN DUNNINGTON NEHALEM ATHLON OPTERON OPTERON_SSE3 BARCELONA BOBCAT ATOM NANO
endif
--8<---------------cut here---------------end--------------->8---

>From that same Makefile, TARGET=GENERIC seems to only do:

--8<---------------cut here---------------start------------->8---
ifdef TARGET
GETARCH_FLAGS := -DFORCE_$(TARGET)
GETARCH_FLAGS += -DUSER_TARGET
ifeq ($(TARGET), GENERIC)
ifeq ($(DYNAMIC_ARCH), 1)
override NO_EXPRECISION=1
export NO_EXPRECiSION
endif
endif
endif
--8<---------------cut here---------------end--------------->8---

I.e. it sets NO_EXPRECISION to 1 and exports it (with a typo!).  Perhaps
good to fix that typo and try it!

> If it weren't for the 2k+ packages which depend on openblas I think it'd
> be obvious to add the extra flags now. I wonder if we could
> unconditionally set DYNAMIC_ARCH=1 TARGET=GENERIC and then override it
> on some architectures, rather than now where each architecture needs its
> own flags.

I've rebuilt core-updates-frozen-batched-changes so many times now I'm
not too afraid of it anymore ;-).

> I also wonder if it's worth it to add a minimal openblas-native for an
> easy transform option of --with-graft=openblas=openblas-native, where
> openblas-native just adds -march=native and turns off substitutability.

Seems this could be done easily by someone already rewriting their Guix
packages graph.

To be continued...

Maxim