While packaging opendkim-1.2.0 with diffheaders which uses libtre I can up with a test error that only occurs with run in the ebuild. Compiling the same program manually didn't generate the test error. The test error was traced to the regex structure being initialized wrong, assumed by the glibc regcomp function, and the comparison occurring in the libtre regaexec (which doesn't occur in glibc). full details ref: http://lists.opendkim.org/archive/opendkim/dev/2009/12/0261.html - last email in thread that hasn't shown up at time of this bug report (I'll attach it next as well). I'm assuming --enable-system-abi should be used when replacing the system's glibc or trying to retrofit this to a binary application. I don't think the current gentoo ebuild should use --enable-system-abi. As a reference debian doesn't either http://patch-tracker.debian.org/patch/debianonly/view/tre/0.8.0-2. I know this is going to cause some ABI transition problems for existing programs linked against libtre however I think its going to be more rugged in the long term if this package maintains its own tre_* library namespace.
Created attachment 212944 [details] error backtraces
I will defer to your judgment. Please do.
Changing this configure option does not help me with 0.8.0 (the configure summary reports 'no' but python module crashes almost always. It seems the glibc incompatibility is still unfixed. I tried to find whether there are some newer patches but except one patch for LOCALE support, nothing. An archive of the not anymore existing mailing list is here: http://www.mail-archive.com/tre-general@laurikari.net/maillist.html The easiest way to get a good stacktrace is: $ gdb python ( gdb ) run testcode.py ( gdb ) where ( gdb ) bt full
Created attachment 264759 [details] gdb-stacktrace1
Created attachment 264761 [details] gdb-stacktrace2
I can also confirm that --enable-system-abi causes severe problems on Gentoo. In my context, it is using libtre from within Python, which resolves the regex API against regex from libc. So regex contexts allocated/initialized by functions specific to libtre are freed by regfree in libc, causing segfaults. The identical code works fine on Debian.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=93098055bb06d347ab414c6ff4f948c7ee9ea367 commit 93098055bb06d347ab414c6ff4f948c7ee9ea367 Author: Alessandro Barbieri <lssndrbarbieri@gmail.com> AuthorDate: 2022-03-15 13:06:07 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2022-03-21 22:06:07 +0000 dev-libs/tre: add 0.8.0_p20210321 Closes: https://bugs.gentoo.org/296813 Closes: https://github.com/gentoo/gentoo/pull/24577 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> Signed-off-by: Alessandro Barbieri <lssndrbarbieri@gmail.com> dev-libs/tre/Manifest | 1 + dev-libs/tre/files/0.8.0-CVE-2016-8559.patch | 7 - dev-libs/tre/files/0.8.0-pkgcfg.patch | 2 - dev-libs/tre/files/tre-chicken.patch | 20 +++ dev-libs/tre/files/tre-issue37.patch | 11 ++ dev-libs/tre/files/tre-issue50.patch | 11 ++ dev-libs/tre/files/tre-issue55-part1.patch | 28 ++++ dev-libs/tre/files/tre-issue55-part2.patch | 11 ++ dev-libs/tre/files/tre-python3.patch | 191 +++++++++++++++++++++++++++ dev-libs/tre/files/tre-tests.patch | 10 ++ dev-libs/tre/metadata.xml | 5 + dev-libs/tre/tre-0.8.0_p20210321.ebuild | 112 ++++++++++++++++ 12 files changed, 400 insertions(+), 9 deletions(-)
