Open phil-blain opened 7 months ago
So, after more investigation, this behaviour only appears on RHEL8, with a self-compiled patchutils 0.4.2 using the system-installed libpcre2 (pcre2-10.32-2.el8.src.rpm
).
It does not appear:
libpcre2
(10.39-3ubuntu0.1
)Turns out, the system where I was seeing this behaviour had LD_PRELOAD=/path/to/libc.so
set in the environment, which caused the libc regcomp
and regexec
functions to be linked at runtime, which explains why I had to use the BRE alternation syntax \|
. And since prec2posix.h
defines REG_EXTENDED=0
, using -E
had no effect.
Note that this would not have happened with pcre2 10.33 or later since the POSIX function names are only defined as preprocessor macros starting in that release: https://github.com/PCRE2Project/pcre2/blob/4a6a8b056f39079d5e958eac84c2ad173f4680bc/ChangeLog#L1050-L1054.
Two things to mention in retrospect:
-E
has no effect, since a user in general does not know how the program was compiled.--with-pcre2=/path/to/self/compiled/pcre2
, it results only in -lpcre2posix
being added to LIBS
, but not in -I/path/to/self/compiled/pcre2/include
being added to CFLAGS
, nor -L/path/to/self/compiled/pcre2/lib
being added to LDFLAGS
, so we end up using the system-installed version of the library.@KangOl CC-ing you since you authored that commit :)
Can you resume the problem ? it is only on RHEL 8 ?
Hi @sergiomb2, in the end, the behaviour I was seeing was caused by LD_PRELOAD
being set by the sysadmins on the system I was using, which I had forgotten about. This is what I wrote in: https://github.com/twaugh/patchutils/issues/60#issuecomment-1982274526. There is nothing much to be done in patchutils on that front, except maybe not using the POSIX names regcomp
and regexec
when compiled with PCRE2, and instead using pcre2_regcomp
and pcre2_regexec
. This would have alleviated the problem.
So the issue can be closed, although I noted two possible improvements in https://github.com/twaugh/patchutils/issues/60#issuecomment-1982285550.
I discovered that if the package is compiled with
--with-pcre2
(which is the default behaviour if libpcre2 is found on the system), then the following invocation does not return anything for the diff copied at the end of this message.Since either
landblockelim
orblockall
are found in several of the hunks, I should get an output. However, if I use the BRE syntax instead:then I get the expected output.
I ran the code through GDB and I see the regexp is correctly passed to
regcomp
withREG_EXTENDED
set, but in<pcre2posix.h>
, which is included instead of<regex.h>
under--with-pcre2
, we have the following:so it seems something is missing for a working "out-of-the box" experience when compiling with libpcre2...
The diff in question: