emerge mariadb10.4 always failed: -- Performing Test PCRE_STACK_SIZE_OK -- Performing Test PCRE_STACK_SIZE_OK - Failed CMake Error at cmake/pcre.cmake:22 (MESSAGE): system pcre is not found or unusable Call Stack (most recent call first): CMakeLists.txt:376 (CHECK_PCRE) After google, it looks like a pcre bug, see https://bugs.exim.org/show_bug.cgi?id=2173 , but I can't see the details due to have no account (and can't create account too). Reproducible: Always
Please attach the full build.log and emerge --info.
Created attachment 865338 [details] emerge --info
Created attachment 865339 [details] build.log
build success if use bundle pcre --- a/dev-db/mariadb/mariadb-10.4.30.ebuild +++ b/dev-db/mariadb/mariadb-10.4.30.ebuild @@ -369,7 +369,7 @@ src_configure() { fi mycmakeargs+=( - -DWITH_PCRE=system + -DWITH_PCRE=bundle -DPLUGIN_OQGRAPH=$(usex oqgraph DYNAMIC NO) -DPLUGIN_SPHINX=$(usex sphinx YES NO) -DPLUGIN_TOKUDB=$(usex tokudb YES NO)
What version of dev-libs/libpcre is installed?
# equery check libpcre * Checking dev-libs/libpcre-8.45-r1 ... 28 out of 28 files passed which is the most recent and only version in portage
I suggest to upgrade to mariadb 10.6 as 10.4/10.5 don't work with openssl-3 (openssl 1.1.1 will be eol soon).
(In reply to Tomáš Mózes from comment #7) > I suggest to upgrade to mariadb 10.6 as 10.4/10.5 don't work with openssl-3 > (openssl 1.1.1 will be eol soon). yes, we'll migrate to mariadb 10.6 eventually. But that won't happen soon, since mariadb 10.4 is still mark as stable, I'd like to continue update it. For now, I;ll use bundled pcre as a solution, thanks.
so.. -- Performing Test PCRE_STACK_SIZE_OK - Failed Fedora are still using https://src.fedoraproject.org/rpms/pcre/blob/rawhide/f/pcre-8.41-fix_stack_estimator.patch - we added the same patch for bug 637648. Could you try figure out why that check is failing for you? CMakeOutput from the build dir may help.
(In reply to Zhixu Liu from comment #8) > (In reply to Tomáš Mózes from comment #7) > > I suggest to upgrade to mariadb 10.6 as 10.4/10.5 don't work with openssl-3 > > (openssl 1.1.1 will be eol soon). > > yes, we'll migrate to mariadb 10.6 eventually. But that won't happen soon, > since mariadb 10.4 is still mark as stable, I'd like to continue update it. > For now, I;ll use bundled pcre as a solution, thanks. I'm migrating my instances to mariadb 10.6 and there's an open PR for masking mariadb 10.4/10.5 (https://github.com/gentoo/gentoo/pull/31847).
(In reply to Sam James from comment #9) > so.. > > -- Performing Test PCRE_STACK_SIZE_OK - Failed > > Fedora are still using > https://src.fedoraproject.org/rpms/pcre/blob/rawhide/f/pcre-8.41- > fix_stack_estimator.patch - we added the same patch for bug 637648. > > Could you try figure out why that check is failing for you? CMakeOutput from > the build dir may help. after check again, I found libpcre is compiled by clang, after recompile libpcre by gcc, problem disappear. I'll continue investigate why clang fails.
after some further analysis, using following test program (copied from cmake/pcre.cmake in mariadb-10.4.30): #include <stdio.h> #include <pcre.h> int main() { int rc; // https://www.pcre.org/original/doc/html/pcreapi.html // int pcre_exec(const pcre *code, const pcre_extra *extra, const char *subject, int length, int startoffset, int options, int *ovector, int ovecsize); // PCRE_ERROR_BADLENGTH (-32) // This error is given if pcre_exec() is called with a negative value for the length argument. rc = -pcre_exec(NULL, NULL, NULL, -999, -999, 0, NULL, 0); printf("%d\n", rc); return rc < 256; } I saw different result when compile libpcre by the most rencent gcc & clang in current portage, see following (I use clang as default compiler): # emerge -Ov1 libpcre; clang a.c -lpcre; ./a.out ; echo $? These are the packages that would be merged, in order: [ebuild R ] dev-libs/libpcre-8.45-r1:3::gentoo USE="bzip2 cxx jit readline (split-usr) (unicode) zlib -libedit -pcre16 -pcre32 -static-libs -valgrind" ABI_X86="(64) -32 (-x32)" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-libs/libpcre-8.45-r1::gentoo >>> Installing (1 of 1) dev-libs/libpcre-8.45-r1::gentoo >>> Completed (1 of 1) dev-libs/libpcre-8.45-r1::gentoo >>> Jobs: 1 of 1 complete Load avg: 4.02, 4.47, 3.53 32 1 y2m ~ # CC=gcc CXX=g++ emerge -Ov1 libpcre; clang a.c -lpcre; ./a.out ; echo $? These are the packages that would be merged, in order: [ebuild R ] dev-libs/libpcre-8.45-r1:3::gentoo USE="bzip2 cxx jit readline (split-usr) (unicode) zlib -libedit -pcre16 -pcre32 -static-libs -valgrind" ABI_X86="(64) -32 (-x32)" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-libs/libpcre-8.45-r1::gentoo >>> Installing (1 of 1) dev-libs/libpcre-8.45-r1::gentoo >>> Completed (1 of 1) dev-libs/libpcre-8.45-r1::gentoo >>> Jobs: 1 of 1 complete Load avg: 4.17, 4.40, 3.56 496 0 You can see, the test return 32 or 496 when libpcre is compiled by clang or gcc. I don't know whether this is a bug of clang or libpcre, and it seems libpcre is eol. At least, I didn't see this problem w/ the earlier clang version.
after downgrade clang to 15.0.7 # clang -v clang version 15.0.7 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/15/bin Configuration file: /etc/clang/clang.cfg System configuration file directory: /etc/clang Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/12 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 # pcretest -m -C PCRE version 8.45 2021-06-15 Compiled with 8-bit support UTF-8 support Unicode properties support Just-in-time compiler support: x86 64bit (little endian + unaligned) Newline sequence is LF \R matches all Unicode newlines Internal link size = 2 POSIX malloc threshold = 10 Parentheses nest limit = 250 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack: approximate frame size = 512 bytes result seems correct, 512 > 256, test will pass. When using clang 16.0.6, result is: # clang -v clang version 16.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/clang.cfg System configuration file directory: /etc/clang Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/12 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 # pcretest -m -C PCRE version 8.45 2021-06-15 Compiled with 8-bit support UTF-8 support Unicode properties support Just-in-time compiler support: x86 64bit (little endian + unaligned) Newline sequence is LF \R matches all Unicode newlines Internal link size = 2 POSIX malloc threshold = 10 Parentheses nest limit = 250 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack: approximate frame size = 32 bytes 32 < 256, test will fail.
had been fixed in https://github.com/MariaDB/server/pull/2700
can someone reassign this to base-system@gentoo.org ?
Thakns for the analysis.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c7ebd2b053695929b4028cabac2744b23a0bb4c6 commit c7ebd2b053695929b4028cabac2744b23a0bb4c6 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-08-03 19:08:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-03 19:08:09 +0000 dev-libs/libpcre: fix attributes w/ clang 16 pcre_exec was optimised, despite the attributes asking it not to, because Clang 16 recognises different tokens. Thanks to Zhixu Liu for the wonderful analysis. Closes: https://bugs.gentoo.org/910188 Signed-off-by: Sam James <sam@gentoo.org> .../libpcre-8.45-fix-stack-size-detection.patch | 18 ++++ dev-libs/libpcre/libpcre-8.45-r2.ebuild | 106 +++++++++++++++++++++ 2 files changed, 124 insertions(+)
