[Rd] zlib+shlib issue with the official EL4 R binary

[Hin-Tak Leung]

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 
>>>> persuade
>>>> 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.

Hin-Tak