https://bugs.exim.org/show_bug.cgi?id=1830
Amir Plivatsky <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from Amir Plivatsky <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
