[Rd] Red Hat 9 regex symbol conflict

[Prof Brian Ripley]

1) .Rout.save files are compared via Rdiff which ignores differences like 
this, so no patch is needed.

2) Can you explore the use of -DUSE_SYSTEM_REGEX, which is designed for 
exactly this sort of problem?

As I understand it, you are getting calls from regex.o in libR.so resolved
into some other library rather than the symbol in the same module.
(re_compile_fastmap is called nowhere else).  If that can happen (and it
seems perverse), surely regcomp and regexp called from e.g. character.o
could get resolved to a library other than libR.so.  I don't see we have
much option but to remap the names R uses to be safe.

On Mon, 28 Apr 2003, Joe Conway wrote:

> Hello,
> 
> I've been struggling with a problem for the past several weeks, trying 
> to get PL/R (R procedural language handler for PostgreSQL, 
> http://www.joeconway.com/plr/) to work on Red Hat 9. In brief, R dumps 
> core during the embedded library initialization, while in Rf_regcomp(), 
> working on on Rprofile. Below I've included the important parts of a 
> backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x420b655c in re_compile_fastmap_iter () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0x420b655c in re_compile_fastmap_iter () from /lib/tls/libc.so.6
> #1  0x420b649d in re_compile_fastmap () from /lib/tls/libc.so.6
> #2  0x403fcb3c in Rf_regcomp (preg=0xbfffb0e0, pattern=0x8ba68a0 
> "[[:blank:]]*([[:alnum:]]+)", cflags=0) at regex.c:5729
> 
> {...snipped...]
> 
> #32 0x403b1015 in R_ReplFile (fp=0x83250d8, rho=0x8321e30, savestack=0, 
> browselevel=0) at main.c:80
> #33 0x403b17aa in R_LoadProfile (fparg=0x0, env=0x8321e30) at main.c:385
> #34 0x403b1984 in setup_Rmainloop () at main.c:503
> #35 0x4045c78f in Rf_initEmbeddedR (argc=4, argv=0xbfffcdb0) at system.c:332
> 
>  From the backtrace it is apparent that re_compile_fastmap() is being 
> resolved to /lib/tls/libc.so.6 instead of the function by the same name 
> in R's regex.c. On the advice of Ulrich Drepper (of the Red Hat glibc 
> team) I was able to get a trace of the symbol resolution process:
> 
> # start PostgreSQL with glibc debugging turned on
> env LD_DEBUG=all LD_DEBUG_OUTPUT=/home/postgres/dbg.out pg_ctl start
> 
> On Red Hat 8 (where everything works), the relevant output looks like this:
> 
>    19097: symbol=re_compile_fastmap;  lookup in file=postgres: postgres
>           regression [local] SELECT
>    19097: symbol=re_compile_fastmap;  lookup in file=/usr/lib/libz.so.1
>    19097: symbol=re_compile_fastmap;  lookup in
>           file=/usr/lib/libreadline.so.4
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/libtermcap.so.2
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/libcrypt.so.1
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/libresolv.so.2
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/libnsl.so.1
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/libdl.so.2
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/i686/libm.so.6
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/i686/libc.so.6
>    19097: symbol=re_compile_fastmap;  lookup in file=/lib/ld-linux.so.2
>    19097: symbol=re_compile_fastmap;  lookup in
>           file=/usr/local/pgsql/lib/plr.so
>    19097: symbol=re_compile_fastmap;  lookup in
>           file=/usr/local/lib/R/bin/libR.so
>    19097: binding file /usr/local/lib/R/bin/libR.so to
>           /usr/local/lib/R/bin/libR.so:
>           normal symbol `re_compile_fastmap'
> 
> On Red Hat 9 (where I get core dumps), the relevant output looks like this:
> 
>    23521: symbol=re_compile_fastmap;  lookup in file=postgres: postgres
>           regression [local] SELECT
>    23521: symbol=re_compile_fastmap;  lookup in file=/usr/lib/libz.so.1
>    23521: symbol=re_compile_fastmap;  lookup in
>           file=/usr/lib/libreadline.so.4
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/libtermcap.so.2
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/libcrypt.so.1
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/libresolv.so.2
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/libnsl.so.1
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/libdl.so.2
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/tls/libm.so.6
>    23521: symbol=re_compile_fastmap;  lookup in file=/lib/tls/libc.so.6
>    23521: binding file /usr/local/lib/R/bin/libR.so to
>           /lib/tls/libc.so.6: normal symbol `re_compile_fastmap'
> 
> The problem exists when using both the 1.6.2 and 1.7.0 versions of 
> libR.so. I have been unable to find a way to prevent this behavior on 
> Red Hat 9 without patching R itself. The attached patch fixes the 
> problem, hopefully in the least obtrusive way. It declares the 
> internal-use-only regex.c functions 'static' instead of 'extern'. There 
> is also a small correction to eval-etc.Rout.save which had an old copyright.
> 
> The patch is against 1.7.0, compiles cleanly, and passes `make check` on 
> my Red Hat 9 machine. I'd appreciate it if you would consider it for 
> inclusion in R-devel, and for any future R.1.7.x release. If a patch 
> against R-devel is needed, I'd be happy to provide that. Alternatively, 
> if someone can suggest a fix that I can apply directly to PL/R, I would 
> also be most appreciative.
> 
> Thank you,
> 
> Joe
> 

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595