Prof Brian Ripley wrote: > 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.
Indeed, "nm libR.so | grep gz" shows the zlib symbols as local (lowercase "t"). I can also confirm that just bundling the zlib source (12 *.c and 10 *.h files, stripped of not-interesting stuff) and remove PKG_LIBS=-lz gives the correct behavior. Thanks a lot for your insights. Hin-Tak ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
