Dirk, Dirk Eddelbuettel <e...@debian.org> writes: > On 21 November 2016 at 23:24, Joseph Mingrone wrote: > | Dirk Eddelbuettel <e...@debian.org> writes: > | > On 20 November 2016 at 21:49, Joseph Mingrone wrote: > | > | Hello Dirk, > | > | > | > | Dirk Eddelbuettel <e...@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@bud:~$ ldd /usr/bin/rkward | grep R # no R libs known to ldd > edd@bud:~$ ldd /usr/bin/rkward | wc -l # lots other shared libraries > 40 > edd@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?
signature.asc
Description: PGP signature
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
