[Rd] zlib+shlib issue with the official EL4 R binary
hin-tak.leung at cimr.cam.ac.uk
Thu Mar 29 19:55:40 CEST 2007
Prof Brian Ripley wrote:
> On Thu, 29 Mar 2007, Hin-Tak Leung wrote:
>> Prof Brian Ripley wrote:
>>> On Thu, 29 Mar 2007, Prof Brian Ripley wrote:
>>>> I presume you are talking about RPMs built with --with-system-zlib?
>>>> That's not recommended in the R-admin manual, and perhaps you can
>>>> Martyn Plummer not to do it.
>>> I've checked, and he no longer does so, sorry. So there is a zlib
>>> inside R, and its entry points will be visible to a packages' .so
>>> when R is built as a binary, but not when it is built as a shared
>>> library. In that case it depends on the fine details (including of
>>> what you did) whether
>>> mypackage.so resolved against R.bin or libz.so in the first two lines
>>> of your table. But it is entirely possible that it links against
>>> R.bin in line 2 and libz.so in line 3.
>>> If your program is that sensitive to the version of libz I think you
>>> should statically link against your own copy (which is R's solution
>>> for its own purposes).
>> Hmm, I have always thought it is the reverse - i.e. when R is built
>> with shlib, the internal version of zlib is exposed to packages' so?
> My belief is that the systems you are considering support visibility
> attributes (but I don't know for sure about EL4 since Redhat versions of
> tools do when the standard ones do not). If so, libR.so does not export
> the zlib entry points.
Indeed, "nm libR.so | grep gz" shows the zlib symbols as
local (lowercase "t").
I can also confirm that just bundling the zlib source (12 *.c and
10 *.h files, stripped of not-interesting stuff) and remove
PKG_LIBS=-lz gives the correct behavior.
Thanks a lot for your insights.
More information about the R-devel