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

[Hin-Tak Leung]

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