Thank you Andrey!

For example, in this case it's not about compilation flags because the relevant code uses SSE2 explictly when USE_SSE2_32IMPL is set. I haven't checked how is it set but the configure step output suggests it checks the hardware support on the build machine, which must not be done in Debian packages. So the first step would be finding how to disable this. There
may be other steps needed.

I've found it -- the flag is conditional on "defined(__i386__)." The code builds once I remove that so I've at least got the beginning of a workaround.

Can you (or anyone) confirm whether the Debian i386 build SHOULD or SHOULD NOT enable SSE of any flavour? I've googled numerous times but can't seem to find this kind of detailed port information.

Thanks again,
-Steve

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 12 Dec 2021 at 12:56:42 -0600, Steven Robbins wrote:

Can you (or anyone) confirm whether the Debian i386 build SHOULD or SHOULD NOT
enable SSE of any flavour?

Our current i386 baseline does not have SSE, so i386 packages should
not enable SSE in general:

"i686 since Debian 9 'stretch' (gcc-6 6.1.1-1). There's no MMX nor SSE."
— https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines

It is OK to have optional use of SSE that is gated by a CPUID check
(I think ioquake3 does this, for example), as long as there is an i387
fallback path that will work correctly on older CPUs where the runtime
check does not detect SSE capabilities.

It is also always OK to use SSE or SSE2 in amd64 binaries (but SSE3
or later is in the same situation as MMX/SSE/SSE2 on i386, and needs a
runtime check).

enable SSE of any flavour? I've googled numerous times but can't seem to find this kind of detailed port information.

https://wiki.debian.org/ArchitectureSpecificsMemo is a useful reference for lots of architecture details.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)