From ripley at stats.ox.ac.uk  Thu Mar 29 16:49:04 2007
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Thu, 29 Mar 2007 15:49:04 +0100 (BST)
Subject: [Rd] zlib+shlib issue with the official EL4 R binary
In-Reply-To: <Pine.LNX.4.64.0703291522480.24561@auk.stats>
References: <460BC6EB.3010502@cimr.cam.ac.uk>
	<Pine.LNX.4.64.0703291522480.24561@auk.stats>
Message-ID: <Pine.LNX.4.64.0703291539130.17915@gannet.stats.ox.ac.uk>

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

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



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