Dirk, Dirk Eddelbuettel <edd at debian.org> writes:> On 20 November 2016 at 21:49, Joseph Mingrone wrote: > | Hello Dirk, > | > | Dirk Eddelbuettel <edd at debian.org> writes: > | > | > On 20 November 2016 at 19:28, Joseph Mingrone wrote: > | > | Hello, > | > | > | > | R's shared libraries are linked without setting the soname. This is causing problems for some consumers. > | > | > | > | Error: /usr/local/lib/R/library/tseries/libs/tseries.so is linked to > | > | /usr/local/lib/R/lib/libRblas.so which does not have a SONAME. math/R needs > | > | to be fixed. > | > | > | > | What's the correct way to add the necessary linker flags? I believe it should be something like this. > | > | > | > | cc -shared -Wl,-soname,... > | > | > I think that may be true "in theory" (for libraries loaded by ldd(8) via > | > `/etc/ld.conf`) but not "in practice" for R which loads these shared > | > libraries itself (via dlopen(3) etc). > | > | R may use dlopen() but other customers may not.> Yes, well, but are there other customers?Yes. Here is one example. https://rkward.kde.org/> | > For what it is worth, I have been providing the Debian packages "as is" for > | > now 15+ years and nobody has complained. > | > | > What system are you on to get that complaint? > | > | This is on FreeBSD. Our apt-get, pkg, will not register shared library dependencies if the shared library does not have a soname. If the library > | gets changed and is no longer compatible with the previous version, and there is no soname to check, pkg will not know that all its dependencies > | need to be reinstalled.> Hmpf. No mechanism for fallback / default soname? In that case you (or > whoever acts as FreeBSD maintainer) may have to supply one.Using a fallback or default soname would defeat the purpose, which is to detect when the library's interface has changed, so that the proper action can be taken. I could provide a local patch for R's autotools, but as a package maintainer yourself, I expect you also prefer when upstream get's it right. Are there any constructive reasons not to include a proper soname? Regards, 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/20161121/edc08748/attachment.bin>
On 21 November 2016 at 23:24, Joseph Mingrone wrote: | Dirk Eddelbuettel <edd at debian.org> writes: | > On 20 November 2016 at 21:49, Joseph Mingrone wrote: | > | Hello Dirk, | > | | > | Dirk Eddelbuettel <edd at debian.org> writes: | > | | > | > On 20 November 2016 at 19:28, Joseph Mingrone wrote: | > | > | Hello, | > | > | | > | > | R's shared libraries are linked without setting the soname. This is causing problems for some consumers. | > | > | | > | > | Error: /usr/local/lib/R/library/tseries/libs/tseries.so is linked to | > | > | /usr/local/lib/R/lib/libRblas.so which does not have a SONAME. math/R needs | > | > | to be fixed. | > | > | | > | > | What's the correct way to add the necessary linker flags? I believe it should be something like this. | > | > | | > | > | cc -shared -Wl,-soname,... | > | | > | > I think that may be true "in theory" (for libraries loaded by ldd(8) via | > | > `/etc/ld.conf`) but not "in practice" for R which loads these shared | > | > libraries itself (via dlopen(3) etc). | > | | > | R may use dlopen() but other customers may not. | | > Yes, well, but are there other customers? | | Yes. Here is one example. https://rkward.kde.org/ Really? We had that eg in Debian too for a decade plus and it works just fine _as is_ and finds its libraries. Without requiring a change. It (AFAIK) just embeds R "as is" (as does my much smaller RInside). edd at bud:~$ ldd /usr/bin/rkward | grep R # no R libs known to ldd edd at bud:~$ ldd /usr/bin/rkward | wc -l # lots other shared libraries 40 edd at bud:~$ | > | > For what it is worth, I have been providing the Debian packages "as is" for | > | > now 15+ years and nobody has complained. | > | | > | > What system are you on to get that complaint? | > | | > | This is on FreeBSD. Our apt-get, pkg, will not register shared library dependencies if the shared library does not have a soname. If the library | > | gets changed and is no longer compatible with the previous version, and there is no soname to check, pkg will not know that all its dependencies | > | need to be reinstalled. | | > Hmpf. No mechanism for fallback / default soname? In that case you (or | > whoever acts as FreeBSD maintainer) may have to supply one. | | Using a fallback or default soname would defeat the purpose, which is to detect | when the library's interface has changed, so that the proper action can be | taken. I could provide a local patch for R's autotools, but as a package | maintainer yourself, I expect you also prefer when upstream get's it right. | | Are there any constructive reasons not to include a proper soname? I fear you are complaining to the wrong person. I am not a committer; just a happy user, packager, and contributor. But as my first email tried to state: nobody here seems to see a problem yet. Best of luck, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Dirk, Dirk Eddelbuettel <edd at debian.org> writes:> On 21 November 2016 at 23:24, Joseph Mingrone wrote: > | Dirk Eddelbuettel <edd at debian.org> writes: > | > On 20 November 2016 at 21:49, Joseph Mingrone wrote: > | > | Hello Dirk, > | > | > | > | Dirk Eddelbuettel <edd at debian.org> writes: > | > | > | > | > On 20 November 2016 at 19:28, Joseph Mingrone wrote: > | > | > | Hello, > | > | > | > | > | > | R's shared libraries are linked without setting the soname. This is causing problems for some consumers. > | > | > | > | > | > | Error: /usr/local/lib/R/library/tseries/libs/tseries.so is linked to > | > | > | /usr/local/lib/R/lib/libRblas.so which does not have a SONAME. math/R needs > | > | > | to be fixed. > | > | > | > | > | > | What's the correct way to add the necessary linker flags? I believe it should be something like this. > | > | > | > | > | > | cc -shared -Wl,-soname,... > | > | > | > | > I think that may be true "in theory" (for libraries loaded by ldd(8) via > | > | > `/etc/ld.conf`) but not "in practice" for R which loads these shared > | > | > libraries itself (via dlopen(3) etc). > | > | > | > | R may use dlopen() but other customers may not. > | > | > Yes, well, but are there other customers? > | > | Yes. Here is one example. https://rkward.kde.org/> Really? We had that eg in Debian too for a decade plus and it works just > fine _as is_ and finds its libraries. Without requiring a change.These are also not fatal errors on FreeBSD, where everything, for now, also just works. ...until a library's interface changes. You seem to be arguing that sonmaes are pointless. We disagree.> It (AFAIK) just embeds R "as is" (as does my much smaller RInside).> edd at bud:~$ ldd /usr/bin/rkward | grep R # no R libs known to ldd > edd at bud:~$ ldd /usr/bin/rkward | wc -l # lots other shared libraries > 40 > edd at bud:~$I can't say for certain (I'm not an rkward user), but looking at the build log, it seems to. Do you have R built as a shared library? Here are select lines from rkward's build log: ... -- Checking for existence of R shared library -- Exists at /usr/local/lib/R/lib/libR.so -- Checking whether we should link against Rlapack library -- Yes, /usr/local/lib/R/lib/libRlapack.so exists -- Checking whether we should link against Rblas library ... ... /usr/bin/c++ -O2 -pipe -I/usr/local/include -fstack-protector -fno-strict-aliasing -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -Woverloaded-virtual -fno-common -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -Wno-return-type-c-linkage -O2 -DNDEBUG -DQT_NO_DEBUG -Wl,-rpath=/usr/local/lib/gcc48 -L/usr/local/lib/gcc48 -B/usr/local/bin -fstack-protector CMakeFiles/rkward.rbackend.dir/rkrbackend.o CMakeFiles/rkward.rbackend.dir/rksignalsupport.o CMakeFiles/rkward.rbackend.dir/rklocalesupport.o CMakeFiles/rkward.rbackend.dir/rkrsupport.o CMakeFiles/rkward.rbackend.dir/rkstructuregetter.o CMakeFiles/rkward.rbackend.dir/rkrbackendprotocol_backend.o CMakeFiles/rkward.rbackend.dir/rkreventloop.o CMakeFiles/rkward.rbackend.dir/rkrbackendprotocol_shared.o CMakeFiles/rkward.rbackend.dir/rdata.o CMakeFiles/rkward.rbackend.dir/rkbackendtransmitter.o CMakeFiles/rkward.rbackend.dir/rktransmitter.o -o rkward.rbackend -L/usr/local/lib -L/usr/local/lib/R/lib -L/wrkdirs/usr/ports/math/rkward-kde4/work/rkward-0.6.5/lib -L/usr/local/lib/qt4 ../../lib/librkgraphicsdevice.backend.a -lR -lRlapack -lRblas -pthread /usr/local/lib/qt4/libQtNetwork.so /usr/local/lib/qt4/libQtCore.so -pthread /usr/local/lib/libintl.so -Wl,-rpath,/usr/local/lib:/usr/local/lib/R/lib:/usr/local/lib/qt4: ...> | > | > For what it is worth, I have been providing the Debian packages "as is" for > | > | > now 15+ years and nobody has complained. > | > | > | > | > What system are you on to get that complaint? > | > | > | > | This is on FreeBSD. Our apt-get, pkg, will not register shared library dependencies if the shared library does not have a soname. If the library > | > | gets changed and is no longer compatible with the previous version, and there is no soname to check, pkg will not know that all its dependencies > | > | need to be reinstalled. > | > | > Hmpf. No mechanism for fallback / default soname? In that case you (or > | > whoever acts as FreeBSD maintainer) may have to supply one. > | > | Using a fallback or default soname would defeat the purpose, which is to detect > | when the library's interface has changed, so that the proper action can be > | taken. I could provide a local patch for R's autotools, but as a package > | maintainer yourself, I expect you also prefer when upstream get's it right. > | > | Are there any constructive reasons not to include a proper soname?-------------- 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/20161122/b3de9c71/attachment.bin>