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>