FS#77058 - [pcre] Namespace some functions

Attached to Project: Arch Linux
Opened by Bruno Pagani (ArchangeGabriel) - Monday, 09 January 2023, 03:21 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:14 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

pcre does not exactly have ABI compatibility for some functions. This leads to crashes when compiling with `--as-needed` (e.g. https://github.com/cyrusimap/cyrus-imapd/issues/2629).

Debian and Fedora have a patch around this:
https://src.fedoraproject.org/rpms/pcre/blob/rawhide/f/pcre-8.42-Declare-POSIX-regex-function-names-as-macros-to-PCRE.patch

Can we consider adding it to our pcre too?
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:14 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/pcre/issues/1
Comment by Toolybird (Toolybird) - Monday, 09 January 2023, 05:48 GMT
Are any current Arch pkgs affected by this? Just curious.
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 09 January 2023, 05:50 GMT
cyrus-imapd that I’m trying to bring into [community].
Comment by loqs (loqs) - Monday, 09 January 2023, 15:33 GMT
Could cyrus-imapd be ported to pcre2 which does not have this issue and is not EOL? This is only build tested but as it is using the posix compatibility interface there should be no differences.
(Note sieve/sieve.c may need to be removed to force it to be regenerated)
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 09 January 2023, 16:03 GMT
There is a ticket upstream about it, https://github.com/cyrusimap/cyrus-imapd/issues/3861. Apparently there is at least one failure in tests, I’ll check with your patch.
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 09 January 2023, 16:09 GMT
I can confirm the test failure:
Test: subject_normalise ...FAILED
1. ./cunit/conversations.testc:1365 - CU_ASSERT_EQUAL(b.len=14,sizeof(_exp)-1=11)
2. ./cunit/conversations.testc:1365 - CU_ASSERT_STRING_EQUAL(b.s="re:nore:foobar",_exp="nore:foobar")
Comment by loqs (loqs) - Monday, 09 January 2023, 22:32 GMT
I made the same mistake as Debian and linked against regcomp from glibc by mistake. How does this updated patch fare?
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 09 January 2023, 22:53 GMT
Still the same.
Comment by loqs (loqs) - Monday, 09 January 2023, 23:16 GMT
Hmm Debian concluded the issue was incorrect linking and pcre2 and pcre were working identically [1]. Out of ideas.
Hopefully upstream will resolve it.

If the namespacing patch is applied could the patch for CET support be applied at the same time?  FS#73355 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000034
Comment by loqs (loqs) - Tuesday, 10 January 2023, 08:49 GMT
All the cunit tests are passing for me with the attached package.
Comment by Bruno Pagani (ArchangeGabriel) - Wednesday, 11 January 2023, 01:18 GMT
Sorry, I’ve missed the step to remove sieve/sieve.c. Adding that and autoreconf from your PKGBUILD made it work indeed. I guess we could remove sieve.c from the pcre2.patch then.
Comment by Bruno Pagani (ArchangeGabriel) - Wednesday, 11 January 2023, 01:24 GMT
@loqs Are you going to report your findings upstream or do you want me to (try to) do so? Also I still see some unneeded linking report by namcap (Unused shared library '/usr/lib/libcyrus_sieve.so.0') even after working around the libtool bug, but no idea whether that’s expected or not (my knowledge of linking is extremely limited).
Comment by loqs (loqs) - Wednesday, 11 January 2023, 08:38 GMT
I have reported the findings upstream. I do not understand the remaining overlinking either.

Loading...