# Build Host to Client Issue: Incompatible processor. This Qt build requires the following features: aes



## freebsdinator (Feb 13, 2019)

Hello,

I have a separate build system which builds ports and distributes them to an old notebook. The notebook does not have AES support.

I have an app that uses QT5 and during the build, it detects the AES feature on the build machine but ignores the make.conf configuration:


```
CPUTYPE?=sandybridge

CFLAGS= -mno-aes #Seems to have no effect.

OPTIONS_SET= CUPS OPENGL PATCHES UTF8 CPUFLAGS CPU_OPTS CPUFLAGS OPTIMIZED_CFLAGS BUILD_OPTIMIZED NONFREE OPTIMIZED_FLAGS VAAPI ALSA SMB OPENCV PGSQL JAVA OSS INTEL SNA
OPTIONS_UNSET= EXAMPLES DOCS NLS DOXYGEN MANPAGES TEST MAN3 V4L OPENCV PULSEAUDIO JACK WAYLAND LIRC CCACHE VDPAU PULSEAUDIO AES SCFB VESA UXA AESNI
```

If I build it on the notebook, there's no issue. It's only when it's built on the newer host.

In the build logs we have:


```
This is the Qt Open Source Edition.

You have already accepted the terms of the Open Source license.

Running configuration tests...
Checking for valid makespec... yes
Checking for target architecture... x86_64
Checking for SSE2 instructions... yes
Checking for AES new instructions... yes
```


```
Configure summary:

Build type: freebsd-clang (x86_64, CPU features: mmx sse sse2)
Compiler: clang 6.0.1
Configuration: sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2 avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi avx512vl compile_examples f16c la
Build options:
  Mode ................................... release
  Optimize release build for size ........ no
  Building shared libraries .............. yes
  Using C standard ....................... C11
  Using C++ standard ..................... C++1z
  Using ccache ........................... no
  Using gold linker ...................... no
  Using precompiled headers .............. no
  Using LTCG ............................. no
  Target compiler supports:
    SSE .................................. SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
    AVX .................................. AVX AVX2
    AVX512 ............................... F ER CD PF DQ BW VL IFMA VBMI
    Other x86 ............................ AES F16C RDRAND SHA
```

But it _does_ see my custom CFLAGS and CPUType:


```
===>  Building for qt5-core-5.12.1
/bin/mkdir -p /construction/xports/devel/qt5-core/work/qtbase-everywhere-src-5.12.1/src/tools/bootstrap
cd /construction/xports/devel/qt5-core/work/qtbase-everywhere-src-5.12.1/src/tools/bootstrap &&  /usr/bin/env QT_SELECT=qt5 QMAKEMODULES="/construction/xports/devel/qt5
--- .obj/qlatincodec.o ---
--- .obj/qtextcodec.o ---
--- .obj/qutfcodec.o ---
--- .obj/qendian.o ---
--- .obj/qlatincodec.o ---
c++ -c -mno-aes -march=sandybridge -fstack-protector -fno-strict-aliasing -fPIC -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -fdata-se
```

Is this an error with my configuration or the port? If it's the port, where would I file a bug report at?


----------



## SirDice (Feb 13, 2019)

I'd remove the CPUTYPE. A Sandybridge CPU has AESNI.


----------



## freebsdinator (Feb 14, 2019)

But the client machine doesn't have AES:

`$ sysctl hw.model hw.machine hw.ncpu

hw.model: Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz

hw.machine: amd64

hw.ncpu: 4`

Intel® AES New Instructions: No 

Code Name Products: formerly Sandy Bridge 









						Product Specifications
					

quick reference guide including specifications, features, pricing, compatibility, design documentation, ordering codes, spec codes and more.




					ark.intel.com
				




To humor you, I recompiled everything with that line removed on the build system and got the same result:

`Incompatible processor. This Qt build requires the following features:
    aes`

The problem is that the build machine _does_ have AES, but the client machine does not. The CPUTYPE being set was meant to help ensure that the build would disable any AES specific code. It seems even the CFLAG disabling it had no impact.


----------



## anurin (Nov 12, 2022)

I met same problem in my build environment...

As current (second) solution, I am using self configured QEMU Build Runner to emulate necessary CPU features.

As first solution, I used a patch to modify Qt sources.
`cat <<EOF > /etc/portage/patches/dev-qt/qtcore:5/IncompatibleProcessorRemoval.patch
--- a/src/corelib/tools/qsimd.cpp
+++ b/src/corelib/tools/qsimd.cpp
@@ -553,24 +553,6 @@
         }
     }
 
-#ifdef RUNNING_ON_VALGRIND
-    bool runningOnValgrind = RUNNING_ON_VALGRIND;
-#else
-    bool runningOnValgrind = false;
-#endif
-    if (Q_UNLIKELY(!runningOnValgrind && minFeature != 0 && (f & minFeature) != minFeature)) {
-        quint64 missing = minFeature & ~f;
-        fprintf(stderr, "Incompatible processor. This Qt build requires the following features:\n   ");
-        for (int i = 0; i < features_count; ++i) {
-            if (missing & (Q_UINT64_C(1) << i))
-                fprintf(stderr, "%s", features_string + features_indices[i]);
-        }
-        fprintf(stderr, "\n");
-        fflush(stderr);
-        qFatal("Aborted. Incompatible processor: missing feature 0x%llx -%s.", missing,
-               features_string + features_indices[qCountTrailingZeroBits(missing)]);
-    }
-
     qt_cpu_features[0].storeRelaxed(f | quint32(QSimdInitialized));
 #ifndef Q_ATOMIC_INT64_IS_SUPPORTED
     qt_cpu_features[1].storeRelaxed(f >> 32);
EOF`


----------

