Rebuilding nearly everything on the chroot under the dev* category with x86-64-v3 as the target ‘cause I keep running into build issues that seem to be related to a mismatch in CPU instruction sets/extensions.

It seems I can build just fine from a Zen 3-based machine targeting a Raptor Lake machine, but some build tools, libraries, and languages really don’t like it if they’re built for the target and the machine they’re running on doesn’t match.

The rest of the packages, I should be just fine building on Zen 3 to target Raptor Lake, but I want the dev libraries and utilities to have a common ground of x86-64-v3.

Basically, I’ve been running CFLAGS="-march=x86-64-v3 -O2 -pipe" CXXFLAGS="-march=x86-64-v3 -O2 -pipe" RUSTFLAGS="${RUSTFLAGS} -C target-cpu=x86-64-v3" emerge --ask --oneshot [category]/[package name]

@maddy On x86 you can have a separate -march and -mtune. -march defines what microarchitecture to build for, so you should build for the lowest common denominator (in terms of extensions) or stuff might not work. -mtune defines what microarchitecture to optimize for, but won’t use instructions that are unavailable on the target instruction set.

I build with -march=haswell -mtune=skylake -maes -mabm to optimize for skylake (which my gentoo machine uses (actually coffee lake refresh but that’s the same microarchitecture)) but so the binaries would still be usable on haswell if I wanted to (-maes is because -march=haswell doesn’t include AES-NI because i3-4000M doesn’t have it for some reason (every other haswell i3 does), -mabm is because resolve-march-native outputted it on skylake and it seems to be present on haswell too)

If some packages built with -march=znver3 fail on raptorlake, it means it’s using some extension not present on raptorlake and you should find out which one and specifically disable it or just build with -march=x86-64-v3 -mtune=znver3.

(On other architectures it may be different. There’s 3 different flags (-march, -mtune, and -mcpu) and what they do is completely inconsistent between architectures)

@maddy Semi-related tip: if you set GOAMD64 to build go packages for a certain microarchitecture level, you shouldn't set it when building the go compiler itself unless you want everything you compile with it to have GOAMD64 set to that value by default. I have GOAMD64=v3 set globally but GOAMD64=v1 for dev-lang/go for this reason (I don't want everything I compile to have GOAMD64=v3 set by default)