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

[Prof Brian Ripley]

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.

> gzeof() is just for detecting end of file - I don't think it is
> a "sensitive" use of zlib. It is just better to be able to tell when
> read failed, whether one has *actually* reach end of file or not.

sensitive _to a particular bug_  There has been such a bug: see the 
comments in gzfile_fgetc and its history.

> I'll try bundling the latest zlib with my package and see if it
> makes any differences... thanks!
>
> Hin-Tak
>
>>> On Thu, 29 Mar 2007, Hin-Tak Leung wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I have got a curious issue with an R package which uses zlib, against
>>>> the official binary here:
>>>> http://cran.r-project.org/bin/linux/redhat/el4/i386/R-2.4.1-1.rh4AS.i386.rpm 
>>>> on a Redhat EL4 i686 system.
>>>> 
>>>> The problem is that at the end of reading a gzip'ed file within my
>>>> C code, gzgetc() returns -1 (no more to read or error) but
>>>> gzeof() doesn't return true. Now one can probably jump to conclusion
>>>> that this is a zlib problem (or mine), but it is not. Here is
>>>> the summary table (my package binary is the same one on the four
>>>> 2.4.1 cases below - built against the official EL4 binary on EL4)
>>>> 
>>>> Rver    shlib   buildhost   runhost    status of zlib code in mypackage
>>>> 2.3.1   no      EL4         EL4        ok
>>>> 2.4.1   no      EL4         EL4        ok
>>>> 2.4.1   yes     EL4         EL4        broken
>>>> 2.4.1   yes     EL4         FC6        ok
>>>> 2.4.1   yes     FC6         FC6        ok
>>>> 
>>>> The most curious part is entry 3 vs 4 - if I just transplant
>>>> the official R binary for EL4 and run it on FC6 (x86_64 and
>>>> loading the same mypackage i686 binary), then it works.
>>>> The dynamic linker on FC6 is very different from all the earlier
>>>> redhat releases [and supposedly a lot faster...].
>>>> (http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Devel.html#id2956225) 
>>>> 
>>>> so it looks like an issue due to a bad interaction for the
>>>> combination of both the shlib compile-time option and the EL4
>>>> runtime environment. (e.g. R 2.4.1 is shipped and bundled with
>>>> zlib 1.2.3 but EL4 is only equiped with zlib 1.2.1.2...).
>>>> 
>>>> For the moment I'll just recommend anybody who needs to run my
>>>> package (snpMatrix in http://www-gene.cimr.cam.ac.uk/clayton/software/)
>>>> on Redhat EL4 to just build and install R from source, since shlib=no
>>>> is the default for compiling from source.
>>>> 
>>>> Anybody has any idea how this strange brokenness of zlib might happen?
>>>> 
>>>> Hin-Tak Leung
>>>> 
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> 
>>> 
>>> 
>> 
>

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