[Rd] shared libraries: missing soname

[Joseph Mingrone]

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>