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.
Not quite - the problematic option seems to be "--enable-R-shlib" which the official RPM was built with (I know there are good reasons, such as various embedded uses). I have actually three 2.4.1 R binaries on EL4: (1) official rpm (linked below) (2) ./configure ; make (; make distclean) (3) ./configure --enable-R-shlib ; make (; make distclean) I have repeat step 2/3 twice (i.e. 2->3->2->3 to make sure it is --enable-R-shlib . I don't think the system zlib is broken per se, because when R is not built with shlib, my package is linked with the system zlib anyway (via PKG_LIBS) and it does work correctly when linked against system zlib. (I have actually tried R CMD SHLIB *.c and fiddle with the last line and manually make my package's shared lib statically linked to zlib, - via copying libz.a to somewhere and doing -L there - but it doesn't seem to help at all). 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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
