Martin Maechler <maechler at stat.math.ethz.ch> writes:> To the issue: I also don't see what your point is. > R works with these so libraries as intended in all cases as > far as we know, and so I don't understand why anything needs to > be changed. > All these libraries "belong to R" and are tied to a specific > version of R and are not be used outside of R, so I also don't see > your point."are not to be used outside of R". You are distributing shared libraries that aren't meant to be shared (outside of R)? But they are. And I gave an example. This is the first sentence of section 3.1.1 [1] of the Linux Documentation Project's -Program Library HOWTO-, "Every shared library has a special name called the 'soname'". I'll ask again, since this was ignored the two previous times I asked it (but I don't expect an answer). Are there any constructive reasons not to include a proper soname in the shared libraries? I will just patch the FreeBSD port. Joseph [1] http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN46 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 930 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20161123/395db973/attachment.bin>
On 22 November 2016 at 22:21, Joseph Mingrone wrote: | Is this a more appropriate example? | | # ldd /usr/local/lib/R/library/tseries/libs/tseries.so | grep libR | libRblas.so => /usr/local/lib/R/lib/libRblas.so (0x80120c000) | libR.so => /usr/local/lib/R/lib/libR.so (0x801c00000) No it is not. Do you see the /usr/local/lib/R/lib here? The trailing R/lib is what Martin and talk about. It means ldd / ldconfig does not know about it -- if you do `ldconfig -p | grep libR` chances are you see nothing. On 23 November 2016 at 06:22, Joseph Mingrone wrote: | Martin Maechler <maechler at stat.math.ethz.ch> writes: | > To the issue: I also don't see what your point is. | > R works with these so libraries as intended in all cases as | > far as we know, and so I don't understand why anything needs to | > be changed. | > All these libraries "belong to R" and are tied to a specific | > version of R and are not be used outside of R, so I also don't see | > your point. | | "are not to be used outside of R". You are distributing shared libraries that | aren't meant to be shared (outside of R)? But they are. And I gave an example. A wrong one though. | I will just patch the FreeBSD port. Please do. You currently are the only one with an itch to scratch, and everybody else is busy. If / when you have a patch which puts a token soname onto every shared library produced [ internally ] by R feel free to offer it to R Core. As Martin told you, so far there is no reason to take it but maybe that will change. Or not. Consider eg this: edd at max:~$ locate Matrix.so /usr/lib/R/library/Matrix/libs/Matrix.so /usr/local/lib/R/site-library/Matrix/libs/Matrix.so /usr/local/lib/R-devel/lib/R/library/Matrix/libs/Matrix.so edd at max:~$ I have three versions of Matrix.so. And still not problem. The third one only enters for R-devel, not R. The first two are distinguished by R itself _by virtue of different paths_ just like Martin and I told you. And _no_ other program on my system knows about Matrix.so: edd at max:~$ ldconfig -p | grep Matrix.so edd at max:~$ ldconfig -p | wc -l 2814 edd at max:~$ ldd / ldconfig do NOT know Matrix.so -- as I told you before -- despite the fact that they know thousands of other things on this (development) machine. All that you said or quoted about soname is fine and handy, and we all respect it __for public libraries like libpng or libxml2. R is different. So if FreeBSD has a problem with that you may indeed have to work around that on the FreeBSD side of things. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Martin Maechler <maechler at stat.math.ethz.ch> writes:> Well, Dirk has said to have given his last reply on this thread. > I (as a member of R-core) am glad about people like Dirk who > take some of our load and helpfully answer such > questions/reports on R-devel.I am glad too. Thank you. My ultimate goal is to ensure that R works as well on FreeBSD as it does elsewhere. It mostly just works (again, appreciative), but there are a few challenges because some R conventions and some FreeBSD conventions may collide. Dirk Eddelbuettel <edd at debian.org> writes:> Consider eg this:> edd at max:~$ locate Matrix.so > /usr/lib/R/library/Matrix/libs/Matrix.so > /usr/local/lib/R/site-library/Matrix/libs/Matrix.so > /usr/local/lib/R-devel/lib/R/library/Matrix/libs/Matrix.so > edd at max:~$> I have three versions of Matrix.so. And still not problem. The third one > only enters for R-devel, not R. The first two are distinguished by R itself > _by virtue of different paths_ just like Martin and I told you.> And _no_ other program on my system knows about Matrix.so:> edd at max:~$ ldconfig -p | grep Matrix.so > edd at max:~$ ldconfig -p | wc -l > 2814 > edd at max:~$> ldd / ldconfig do NOT know Matrix.so -- as I told you before -- despite the > fact that they know thousands of other things on this (development) machine.For a frequently-updated Debian package repository, I assume you _manually_ bump all the Debian R packages whenever the main R package is upgraded. Is that correct? That is, when a Debian user upgrades the r-base package from, say, version 3.2.5 to 3.3.1, then r-cran-tseries must/should be rebuilt/reinstalled against the new R package? If so, maybe there is something useful we could submit. I will have to study how R uses autotools, because that also seems a bit different than I am used to. I also notice that on Debian you make a soft link of /usr/lib/R/lib/libR.so to /usr/lib/libR.so. Given all that has been discussed, I am unclear why. Thank you for sticking with the thread, Joseph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 930 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20161124/be4da4d3/attachment.bin>