Generated code seems to depend on the CPU on which it was built

[KritonK]

This issue is unique.

• I have used the search tool and did not find an issue describing my bug.

Operating System

Linux

Architecture

x86_64

Package Type

rpm

Version information

git commit 16d1a01

Expected Behavior

I built Euro-Office from source under OpenSUSE Tumbleweed, using build.sh on a computer with an "Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz" according to /proc/cpuinfo. The resulting code runs fine on this computer.

The expected behavior is that the code should also run on my home computer, which has an older "Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz".

Actual Behavior

On my home computer, Euro-Office aborts, with the following error:

Incompatible processor. This Qt build requires the following features:
    sse4.2 popcnt

Reproduction Steps

1. Build Euro-Office on a computer whose CPU supports the sse4_2 popcnt instruction set.
2. Install and run it on a computer which does not.

Additional information

I'm a bit hazy on dates, but I think that a build that I made about two weeks ago ran fine on my home computer, in which case this is a recent regression. ONLYOFFICE does not have this problem, so this is not something that has been inherited from there.

I suspect that Qt and perhaps other code as well are compiled using "-march=native", instead of requiring a more generic architecture.

[rikled]

Thanks for raising that. This is related to Euro-Office/DocumentServer#13 I think.

[pplupo]

@rikled I think this failure is expected behavior on pre-Nehalem hardware due to modern Qt framework dependencies.

To ensure Euro-Office aligns with modern security and compliance standards, I recommend officially establishing x86-64-v2 as the minimum architectural baseline for this project.

The x86-64-v2 microarchitecture level explicitly guarantees support for modern instruction sets, including SSE4.2 and POPCNT. Enforcing this baseline is critical for several security and maintainability reasons.

Operating systems have dropped support for pre-x86-64-v2 hardware to enforce better security models. (Windows kernels now have a strict, non-bypassable dependency on the POPCNT instruction).
Core frameworks like Qt heavily rely on SSE4.2 and modern vector instructions for safe and performant execution. Maintaining custom build flags to support legacy instruction sets prevents us from fully utilizing upstream security patches and introduces unnecessary risks by keeping older, unoptimized fallback code paths active. It will increase the burden to maintain the codebase.

As a digital sovereignty project, the software must target modern, secure, and standardized environments. Hardware lacking modern instruction sets also lacks critical hardware-level exploit mitigations (such as protections against speculative execution vulnerabilities). I don't think we'll find many users in the public and private sectors using computers with such liabilities.

Asking hbow to rebuild it to run on an older computer like Euro-Office/DocumentServer#13 is totally valid. I don't think we should treat it as a defect, though.

[KritonK]

Operating systems have dropped support for pre-x86-64-v2 hardware

"Operating Systems" does not mean "Windows" and Red Hat. I am running OpenSUSE Tumbleweed, which is a rolling Linux release, with the latest version of all software, and I can assure you that it supports old x86-64 hardware just fine.

Core frameworks like Qt heavily rely on SSE4.2 and modern vector instructions

I thought Qt is written in a high level language, and can use whatever instructions the compiler chooses to generate. It is already installed in OpenSUSE Tumbleweed, and runs fine without SSE4.2.

As a digital sovereignty project, the software must target modern, secure, and standardized environments.

As a digital sovereignty project, it should target the widest possible base, so that it gets as widely adopted as possible and becomes the default office platform. If people need to buy new computers just to run Euro-Office, many of them will simply look elsewhere. At work we currently use ONLYOFFICE, and it will be hard for me to recommend switching to Euro-Office, if it is has limitations.

In any case, whatever architecture Euro-Office chooses to support in pre-built binaries, this should not affect building the project from source. At the very least, a simple way to specify the target architecture should be provided. Right now, with the complex, docker-based build environment, that is required to build Euro-Office, I don't even have an idea where to look.

A quick find . -type f -print0 | xargs -0 grep "arch=native" shows that -march=native is hardwired in a few places, which suggests that if the official Euro-Office binaries are built on a modern computer (which they should, for speed), the CPU requirements of these binaries will be x86-64-v4, not x86-64-v3:

./desktop-sdk/ChromiumBasedEditors/lib/qt_wrapper/CMakeLists.txt:#add_compile_options(-march=native)
./core/DesktopEditor/raster/Jp2/openjpeg/openjpeg-2.4.0/INSTALL.md:cmake -DCMAKE_C_FLAGS="-O3 -march=native -DNDEBUG" ..
./core/Common/3dParty/cryptopp/chacha_simd.cpp://    way of -march=native), then we can pull another 150 to 800 MB/s out of
./core/Common/3dParty/cryptopp/GNUmakefile:  # GCC's -march=native, which we don't really want.
./core/Common/3dParty/cryptopp/GNUmakefile:  TOPT = -march=native
./core/Common/3dParty/cryptopp/GNUmakefile:    NATIVE_OPT = -march=native

[pplupo]

"Operating Systems" does not mean "Windows" and Red Hat. I am running OpenSUSE Tumbleweed, which is a rolling Linux release, with the latest version of all software, and I can assure you that it supports old x86-64 hardware just fine.

Upcoming releases like openSUSE Leap 16.0 mandate x86-64-v2, and Windows 11 enforces POPCNT at the kernel level. This is a general trend that is not new. Older systems in general won't be adopted in governments and enterprise settings because they are not secure enough.

I thought Qt is written in a high level language, and can use whatever instructions the compiler chooses to generate. It is already installed in OpenSUSE Tumbleweed, and runs fine without SSE4.2.

Qt heavily utilizes hand-coded SIMD intrinsics (like SSE and AVX) for core operations, such as string manipulation and rendering, rather than relying solely on compiler auto-vectorization. While Qt can be built without SSE4.2 using fallback paths, doing so requires custom configurations and degrades performance.

As a digital sovereignty project, it should target the widest possible base, so that it gets as widely adopted as possible and becomes the default office platform.
The Intel Core 2 Duo E8600 was released in 2008. In 2026, targeting an 18-year-old CPU for a "secure" digital sovereignty project introduces significant liabilities. Pre-Nehalem processors lack critical hardware-level mitigations for side-channel vulnerabilities (like Spectre and Meltdown) and no longer receive microcode updates.

A quick find . -type f -print0 | xargs -0 grep "arch=native" shows that -march=native is hardwired in a few places, which suggests that if the official Euro-Office binaries are built on a modern computer (which they should, for speed), the CPU requirements of these binaries will be x86-64-v4, not x86-64-v3:

I re-checked the raw bytes of all four locations directly (not just grep context). Here's what I found:

1. desktop-sdk/.../qt_wrapper/CMakeLists.txt line 10 — I ran cat -A (shows all invisible characters) on this file, and the # genuinely is the very first character of the line:

#add_compile_options(-march=native)$

No leading whitespace, no other content before it — this is a standard CMake comment. If you're seeing something different in your editor, it might be a rendering/tab issue, but the file on disk has # at column 1. This line is inactive.

2. openjpeg-2.4.0/INSTALL.md — confirmed via raw bytes it's inside a markdown code fence (```), part of prose documentation showing a manual/standalone build example. Nothing in this repo's actual CMake integration for OpenJPEG reads or executes this file.

3. cryptopp/GNUmakefile — I found the real context this time (I only grepped the flag itself before, not the surrounding conditional). Lines 990-1005 show it's gated behind:

ifeq ($(findstring native,$(MAKECMDGOALS)),native)

This only activates if someone explicitly runs make native as the target — it's cryptopp's own opt-in test/tuning target from its standalone build system. I confirmed no script, Dockerfile, or CI workflow in this repo ever invokes make inside the cryptopp directory at all — the project builds cryptopp exclusively via add_subdirectory(.../cryptopp/project CryptoPPLib) in CMake, and that path's own CMakeLists.txt has zero -march references.

4. chacha_simd.cpp — confirmed it's inside a // comment block explaining SIMD runtime-detection logic, not a compiler directive.

All four checks hold: none of these are active in the actual build path. If you're still seeing something that contradicts this, can you point me to the specific line/file where you're seeing it differently? I'd rather verify against your exact observation than argue past each other.

Euro-Office/DocumentServer#13 is literally about how t successfully do what you are asking for. Have you taken a look at it?

[KritonK]

It is good to hear that -march=native is actually not being used.

Like I said, OpenSUSE Tumbleweed is bleeding edge Linux, does not require x86-64-v2 or higher, and does provide Qt6. The fact that some distributions have upped their CPU requirements does not mean that all of them have. If the euro-office build process pulls pre-compiled Qt6 binaries, because Qt6 is huge, then euro-office should make its own Qt6 build and the build process should pull that, instead of the official pre-built binaries, if the latter require x86-64-v2,

Please don't confuse "I have a great, modern computer" with "everyone has a great, modern computer". Especially if you are a developer, where, by definition, you absolutely need such a computer, if you are to compile modern software in a reasonable amount of time; not everyone is a developer.

I understand one's frustration of having one's computer underutilized by running plain x86-64 binaries, but there is a reason that this is not the default everywhere. I don't know what OpenSUSE Leap is doing, but there was a discussion about upping the CPU requirements for OpenSUSE Tumbleweed, and after several objections the proposal was withdrawn.

As for looking at Euro-Office/DocumentServer#13, I can't make heads or tails of it. Last time I wrote code, it was back in the days when one would use only configure and make. These days, I am a plain user, and all I know is that I cannot run Euro-Office on my computer. The last two comments in that issue, "Unfortunately it is not enough", and "It seems the issue of not working instance is solved in the latest release" do not make me particularly hopeful that this is a problem that can be handled by someone like myself. On the other hand, they suggest that this is something that can be fixed at Euro-Office's end, and a month ago had actually been fixed for a while. Perhaps whatever was done then, needs to be done again.

[pplupo]

I haven’t once used my own hardware as the basis of my argument, yet you’re treating my personal computer setup as if it were central to my point. For context only, my laptop’s CPU and one of my desktop CPUs are both about 8 years old, and only my gaming PC has a 2‑year‑old CPU. My point is simply that hardware this old generally lacks modern security features, which makes it a poor fit for the vast majority of users, especially in government and business environments where stronger guarantees are needed.

With that in mind—and since this issue is really about generated code depending on the CPU it was built on, rather than about providing binaries for older CPUs—I’m inclined to think the core concern here has been addressed.

If the build steps in Euro-Office/DocumentServer#13 aren’t immediately clear or feel a bit overwhelming, that’s completely understandable—they’re not exactly beginner-friendly. Still, that discussion does describe an approach for handling the scenario you’re running into: Euro-Office/DocumentServer#13.
So far, there’s no evidence that hardcoded constants are forcing incompatibility with older hardware. Even if it did turn out that such constants exist, adjusting them would require some development experience to produce a custom build for personal use—which is exactly the kind of flexibility open-source software is meant to provide. People are free to adapt the code to their specific needs, and that alone doesn’t imply there’s a defect in the software itself.

From my perspective, based on the above, this doesn’t appear to be a software issue.

[KritonK]

I am simply trying to understand why you are so opposed to fixing the issue. @rikled's acknowledgment was enough for me, as I do not expect that the issue will be fixed immediately, only that it is dealt with before official packages are released. Opposing fixing the issue was the last thing I expected!

The suggestion that the problem is that the binaries are built for the architecture of the CPU, on which they were compiled, was purely my guess. It now looks like this may not be the case. Google Gemini suggested that the build process is pulling pre-built binaries, which is why I mentioned pulling pre-built Qt6 binaries in my previous message. Feel free to change the issue subject to something more appropriate, if my guess was, indeed, wrong.

I will try to build Euro-Office on my home computer during the weekend. If the produced binaries are running fine there, then something must be using "-march=native". Otherwise, either something is being compiled for a higher architecture, or a pre-built binary built for a higher architecture is being pulled.

[pplupo]

If this is simply a matter of building dependencies locally when building for older hardware, then I'd tend to agree with you that this is an enhancement that could be dealt with.

@rikled I'm suspecting that this may be due to the qt6 migration.
I'm not stating that this is definitely the case, but given the timelines and what I came to learn about qt6, it's a strong candidate.
To support hardware that predates SSE4.2 (such as the Intel Core 2 Duo), we cannot rely on pre-built Qt 6 packages that target x86-64-v2. We must compile the Qt 6 framework from source in your build environment, ensuring that modern architecture compiler flags like -march=x86-64-v2, -msse4.2, or -mpopcnt are absent or explicitly overridden. Any software linking against this custom Qt build must also be compiled to target the same baseline architecture.

It may be an enhancement to the build pipeline to create some sort of flag to switch the entire build process to compile all the dependencies from scratch to expand compatibility to outdated hardware.
However, if we miss a single dependency (i.e., pull the binaries, thinking they are compatible with outdated hardware when they are not), it will still run on our computers. The problem will also cascade to transitive dependencies.

And the build process is already quite long.

I'm not sure how we could maintain this. But if this is the case, I propose that this is an enhancement.

[KritonK]

Some good news:

I was able to run euro-office on my Core 2 duo at home, by building Qt 6.10.1 from source. I built it on my i7 960 at work, without specifying any CPU options, which shows that the compilation process uses the default CPU options for the build platform, without having any CPU options hardwired. In fact, using ps, I was able to see that cc1plus was running with "-march=x86-64", which presumably it picked up from the gcc configuration for OpenSUSE Tumbleweed.

The files I replaced in /opt/euro-office/desktopeditors were libQt6* and the platforms folder, which contains the Qt plugins.

Looking at the bundled libQt6* files, I see that they contain the string "GCC: (GNU) 11.4.1 20231218 (Red Hat 11.4.1-3)", which suggests that Qt was compiled on a Red Hat 9 system or a clone thereof, which has higher CPU requirements than x86-64.

Thus, I see various options to resolve this issue:

1. If euro-office is using official pre-compiled binaries, contact the Qt people and ask them to compile their binaries for x86-64 and not to use the default Red Hat compilation options. This may be as simple as adding -DCMAKE_C_FLAGS="-march=x86-64 -mtune=generic" -DCMAKE_CXX_FLAGS="-march=x86-64 -mtune=generic" to cmake, as Gemini suggested. If they agree to do this, they will probably only do it for new Qt releases, which may be a problem, if euro-office relies on using Qt 6.10.1.
2. Build a version of Qt for x86-64 once, and pull that, instead of the official Qt binaries, when building euro-office. This can be compiled in whatever distribution the docker environment that is used to build euro-office uses, as it produces plain x86-64 binaries.
3. Do not bundle Qt at all, and rely on the system version of Qt6. I don't know if this even possible, given the proliferation of Qt6 versions in various distributions (e.g., Red Hat 9 uses Qt 6.6, OpenSUSE Tumbleweed uses 6.11.1) and that some older distributions, that are still current (e.g., Red Hat 8), do not have Qt6 at all. In addition, euro-office seems to be using version-dependent, private Qt APIs. When I removed libQt6*, hoping to use the system versions instead, I got the error: /opt/euro-office/desktopeditors/DesktopEditors: /lib64/libQt6Gui.so.6: version `Qt_6_PRIVATE_API' not found (required by /opt/euro-office/desktopeditors/libqtascdocumentscore.so)

What I would not suggest is to have affected users compile Qt themselves, or making the compilation of Qt part of the build process. It took me several attempts to build Qt, with my computer being brought to its knees by thrashing, as the 16 GB, that I have, is too little for the massive amount of parallelism that the Qt build process uses by default. At the suggestion of Gemini, I specified:

export NINJAJOBS=1
export NINJAFLAGS="-j 1"

before running cmake, which compiled all files sequentially, but took about 24 hours to complete! On my 8 GB Core 2 Duo it would have taken about four times as much!

[pplupo]

Here is an evaluation of the proposed suggestions, the performance implications, and an alternative approach moving forward.

Evaluation of Proposed Suggestions

• Contacting Qt to change official binaries: Upstream framework maintainers design releases to leverage current instruction sets for baseline performance and are highly unlikely to downgrade global defaults to support legacy hardware.
• Building a custom Qt for x86-64: While technically viable, this shifts a massive maintenance burden onto the team to manage a custom compilation pipeline for a heavily parallelized framework and assume responsibility for tracking and integrating upstream security patches.
• Relying on system Qt6: This approach is brittle due to the fragmentation of Qt versions across Linux distributions and the project's reliance on version-dependent, private Qt APIs (Qt_6_PRIVATE_API), which causes immediate linking failures when bundled libraries are removed.

Performance Impact

Implementing these suggestions globally would have a significant negative impact on performance. Qt heavily utilizes hand-coded SIMD intrinsics, such as SSE and AVX, for core operations like string manipulation and rendering. Compiling Qt without targeting modern architectures (like x86-64-v2) strips out sse4.2 and popcnt instructions, forcing the framework to rely on unoptimized fallback code paths for all users to accommodate legacy hardware.

Alternative: Community-Maintained Legacy Builds

Rather than downgrading the official baseline (with the SIMD regression described above) or having the core team own a second, permanently-tracked Qt build pipeline, we can make the target architecture a build-time parameter (-march=x86-64-v2 by default, overridable) in the build scripts. This lets anyone who needs a baseline x86-64 build compile Qt and the application themselves from the same sources we ship, and optionally distribute the result (e.g. as an AUR package, a Flatpak branch, or a personal repo) — without the core team taking on responsibility for testing, security-patching, or supporting a second Qt build against hardware we don't have.

To be clear about scope: this isn't a one-flag --legacy experience. Since system Qt6 is ruled out (private API dependency) and a second official Qt build isn't something the team should have to maintain, someone going this route would need to rebuild Qt from source themselves against the baseline target — the flag just makes that possible instead of fighting the build system. My suggestion is that official releases, CI, and support stay scoped to x86-64-v2, with this as the supported escape hatch for legacy hardware.

Implementation Sketch

For anyone interested in pursuing this, here's roughly what it would take on our current build setup:

• Qt itself is built via vcpkg (core/vcpkg.json, feature desktop-editors), riding the stock x64-linux community triplet — there's no custom triplet in the repo yet. A legacy build would need a new triplet (e.g. x64-linux-baseline.cmake) setting VCPKG_CXX_FLAGS/VCPKG_C_FLAGS to -march=x86-64, since that's the layer where Qt actually gets its compiler flags.
• That triplet would need to be selectable via -DVCPKG_TARGET_TRIPLET=... in the cmake invocations in both core.bake.Dockerfile and desktop-apps.bake.Dockerfile, threaded through as a build arg in docker-bake.hcl and exposed as a flag/env var in build.sh.
• The core/V8 build's existing CMAKE_CXX_FLAGS_RELEASE="-O3 -w" (core.bake.Dockerfile:160) would need the same -march value applied, so a baseline build doesn't end up with a v2-only core linked against baseline Qt.
• vcpkg's binary cache is already keyed by triplet, so a legacy build would land in its own cache bucket without touching the official v2 cache — nothing extra needed there.

It's a fairly contained, additive change and wouldn't touch the default (v2) build path at all.

I understand this is not what you would suggest, but I think the problem you raised can be mitigated by a community-supported fork of the project that runs the build and distributes the release.

[KritonK]

I'm sorry, but this review reads like something that is AI-generated and extremely prejudiced.

• "Upstream framework maintainers design releases to leverage current instruction sets"?
• "Qt heavily utilizes hand-coded SIMD intrinsics, such as SSE and AVX"?

I simply made a default build without trying to circumvent anything. If Qt had specified higher CPU optimization flags or had hand-coded SSE and AVX instructions, my build would have produced code that does not run on lower CPUs. The only reason the Qt binaries use newer instructions is because this is the default gcc setting on the system on which they were built.

Given all this, I shudder to think what would happen if I were to report a bug that needs fixing, but is hard to do so. Therefore, my evaluation of Euro-Office for using it at work ends here, and my recommendation will be to stay with onlyoffice, which does fix bugs when reported.

Thank you for making my decision easy.

[pplupo]

This is not a bug. It's an enhancement. Many bugs have been fixed. Also, I do not speak for the team, I'm only a small contributor.

And yes, I used AI to rewrite what I said and help me find alternative ways to support your request.

If Qt had specified higher CPU optimization flags or had hand-coded SSE and AVX instructions, my build would have produced code that does not run on lower CPUs.

Qt heavily utilizes hand-coded SIMD intrinsics (SSE, AVX, NEON) extensively throughout its codebase for modules like QtGui and QtCore. The reason his local build runs on his Core 2 Duo is due to how Qt handles SIMD:

Runtime Feature Detection (Dynamic Dispatch): For many optimizations, Qt compiles multiple code paths and checks the CPU capabilities at runtime. If the CPU lacks AVX or SSE4.2, the framework falls back to a slower, generic C++ implementation.

Compile-Time Gating: If the baseline architecture provided to the compiler does not support SSE4.2 (which is the case when he built it without flags, defaulting to the generic x86-64 baseline of his OpenSUSE environment), the build system simply excludes the mandatory SIMD paths or relies exclusively on the fallback C++ code.

Your successful build did not disprove the existence of hand-coded SIMD; it simply proved that building Qt without modern architecture flags forces the framework to compile its unoptimized fallback paths.

I took the time to check all the flags and code needed to make the compilation easier for older hardware. This is not a refusal; it's a map on how to do it. I'm actually recommending that we make these changes.

This is not a "hard to fix bug." It's a "hard to maintain enhancement."It's a real burden to support this the way you like. Bear in mind that most of us (if any) won't even have a way to test it properly, which would need to be done with every release. That's why I'm suggesting that interested parties in the community fork it after the changes and set up the build there, with the necessary flags, and rebuild the dependencies, exactly how you did (but easier with the changes I'm suggesting).

[pplupo]

@KritonK , I've done the implementation to enable the suggestion to hopefully address your concerns. I was never "against" the enhancement, just finding a way to address it in a supportable manner.

Euro-Office/core#125
Euro-Office/desktop-apps#35
#61