https://bugs.exim.org/show_bug.cgi?id=1830
Amir Plivatsky <amirpli@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amirpli@???
--- Comment #11 from Amir Plivatsky <amirpli@???> ---
This bug is marked as resolved and fixed, but the original reported problem has
not really been resolved (the workaround of embedding the pcre2posix source
code is not an option in many cases).
When linking a program or library that originally uses POSIX regex, one can be
careful/creative with specifying the linker arguments to get libpcre2-posix
before libc, and then all is fine and this problem doesn't happen.
However, if such a library is loaded as an extension module (to Python in my
case), then the libc regexec/regcomp (etc.) functions are used, as the python
binary is linked against libc.
>From LD_DEBUG trace:
3565971: symbol=regcomp; lookup in file=python2 [0]
3565971: symbol=regcomp; lookup in file=/lib64/libpython2.7.so.1.0 [0]
3565971: symbol=regcomp; lookup in file=/lib64/libpthread.so.0 [0]
3565971: symbol=regcomp; lookup in file=/lib64/libdl.so.2 [0]
3565971: symbol=regcomp; lookup in file=/lib64/libutil.so.1 [0]
3565971: symbol=regcomp; lookup in file=/lib64/libm.so.6 [0]
3565971: symbol=regcomp; lookup in file=/lib64/libc.so.6 [0]
3565971: binding file /tmp/.../MYLIB.so.5 [0] to /lib64/libc.so.6 [0]:
normal symbol `regcomp'
The symbol resolution here is against the libraries defined in the
system-install python2, and I cannot add there libpcre2-posix before libc
without hacks or using LD_PRELOAD.
(The actual problem that happens can be hard to debug - an malloc() fault in
the above case.)
In Comment 1 Philip Hazel wrote:
> The whole point of the POSIX wrapper is that existing programs can link with it without modification.
In Comment 6 Philip Hazel wrote:
> Your "trick" would require recompiling, or somehow modifying the already-compiled application.
> I am very loath to make incompatible changes because, however rare you think dependence on some feature may be, there is always sure to be somebody who gets caught out.
I propose the following compatible change:
In addition to adding the previously proposed defines like "#define regcomp
pcre2posix_regcomp",
add "pcre2posix_regcomp" (and the like for regexec/regerror/regfree) as a
synonym to the POSIX function names. This way existing programs would not get
affected.
This can be done in a number of ways, the simplest one is maybe something like:
int pcre2posix_regcomp(regex_t *preg, const char *regex, int cflags)
{
return regcomp(preg, cregex, cflags);
}
(Let the compiler to optimize the extra call, or even put it with "inline" in
pcre2posix.h if desired, but I think there is no need for that.)
--
You are receiving this mail because:
You are on the CC list for the bug.
