This appears to be an intended change in glibc 2.41 after doing some more searching, adding the version to the search context. Here are a few other examples where this same issue is happening.
- Crash under glibc 2.41 due to libopenlibm having an executable stack · Issue #57250 · JuliaLang/julia · GitHub
- Python ctranslate2 breaks with glibc 2.41: cannot enable executable stack · Issue #1849 · OpenNMT/CTranslate2 · GitHub
- [L4D2] engine.so: cannot enable executable stack as shared object requires: Invalid argument · Issue #6978 · ValveSoftware/Source-1-Games · GitHub
The particular release note item that seems relevant from https://lists.gnu.org/archive/html/info-gnu/2025-01/msg00014.html is this:
* dlopen and dlmopen no longer make the stack executable if a shared
library requires it, either implicitly because of a missing GNU_STACK
ELF header (and default ABI permission having the executable bit set)
or explicitly because of the executable bit in GNU_STACK, and the
stack is not already executable. Instead, loading such objects will
fail.
One workaround mentioned could be the following:
execstack -c libnvinfer_builder_resource.so.10.8.0
If this works we’ll need to ensure the library is built with this flag cleared. If not then the solution could be more complicated.