[glenn-jocher]

Fixes #3390.

Problem

On Linux with glibc 2.41+ (Ubuntu 25.04+/26.04 LTS, Debian 13, Fedora 42+, Arch), import MNN fails with the published x86_64 wheels:

ImportError: .../site-packages/_mnncengine.cpython-314-x86_64-linux-gnu.so: cannot enable executable stack as shared object requires: Invalid argument

All MNN 3.6.1 manylinux2014_x86_64 wheels (cp311–cp314) mark _mnncengine and _tools as RWE in PT_GNU_STACK. The aarch64 wheels are RW and load fine.

Cause

The x86_64 assembly kernels in source/backend/cpu/x86_x64/**/*.S have no .note.GNU-stack section, so GNU ld assumes they need an executable stack and marks every library linking them that way. The kernels never execute code on the stack. glibc 2.41 stopped allowing dlopen of such libraries.

Fix

All 13 x86_64 .S files include source/backend/cpu/x86_x64/MNNAsmGlobal.h, so declaring the note once there (for ELF targets only) covers every kernel:

#ifdef __ELF__
.section .note.GNU-stack,"",%progbits
#endif

Validation

• quay.io/pypa/manylinux2014_x86_64 toolchain (GCC 10.2.1, ld 2.35): _AVX_MNNGemmFloatUnitMainFMA.S linked into a shared object gives GNU_STACK RWE before, RW after.
• Full pymnn wheel built in that image with build_deps.py, setup.py bdist_wheel and auditwheel repair (cp314): _mnncengine and _tools are both RW.
• That wheel installed in a stock ubuntu:26.04 container (glibc 2.43, Python 3.14.4): import MNN and from MNN.tools import mnnconvert succeed, where the PyPI 3.6.1 wheel fails as above.