[Rd] zlib+shlib issue with the official EL4 R binary
hin-tak.leung at cimr.cam.ac.uk
Thu Mar 29 16:59:30 CEST 2007
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)
> 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?
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.
I'll try bundling the latest zlib with my package and see if it
makes any differences... thanks!
>> On Thu, 29 Mar 2007, Hin-Tak Leung wrote:
>>> I have got a curious issue with an R package which uses zlib, against
>>> the official binary here:
>>> 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...].
>>> 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 18.104.22.168...).
>>> 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
More information about the R-devel