When investigating the FTBFS below, I found that pcre2_match_8 was dereferencing the subject pointer argument even when its length was 0. In the case of an empty string in Rust, it was passing 0x1 as a non-null aligned pointer, length 0. A SIGSEGV only occurred in the aarch64 build, which suggests to me that the rogue deref is specific to aarch64 JIT.

It seems to be fixed in Fedora's version of pcre2, because the exact same test binary that crashed on c9s will pass on Fedora. I don't know what the change was since pcre2 10.40 though.

The rust-pcre2 wrapper has release a 0.2.9 update to work around this, ensuring that it always passes a dereferenceable pointer even when the length is 0.

Description of problem:
Package rust-ripgrep fails to build from source in EPEL 9 NEXT.

Version-Release number of selected component (if applicable):
14.1.0-3.el9

Steps to Reproduce:
koji build --scratch epel9-next rust-ripgrep-14.1.0-3.el9.src.rpm

Additional info:
This package is tracked by Koschei. See:
https://koschei.fedoraproject.org/package/rust-ripgrep