Dynamische Verknüpfung mit rpath funktioniert nicht unter Ubuntu 17.10

Question

Ich baue ein R-Paket, das Rcpp und Links zu einem freigegebenen Objekt von Drittanbietern (libbarraopt.so) verwendet (die auch auf andere gemeinsame Objekte wie liboptsrvr.so in einem eigenen Verzeichnis verweist). Um sicherzustellen, dass es in der Lage ist, diese gemeinsamen Objekte es Links gegen, habe ich die folgenden Variablen in ~/.Renviron zu finden:

BARRA_OPS_HOME=${HOME}/bin/BarraOptimizer8.5 

Im Paket, ich schaff' die folgenden src/Makevars:

BARRA_LIB=$(BARRA_OPS_HOME)/lib/intel64 
BARRA_INCLUDE=$(BARRA_OPS_HOME)/include 
PKG_CXXFLAGS=-I$(BARRA_INCLUDE) 
PKG_CFLAGS=-I$(BARRA_INCLUDE) 
PKG_LIBS=-L$(BARRA_LIB) -Wl,-R,$(BARRA_LIB) -lbarraopt 

Unter Ubuntu 16.04 Ich kann das Paket ohne Probleme erstellen, laden und verwenden. Allerdings, wenn ich genau das gleiche Paket testen, wenn OS auf 17,10 aktualisiert wird, kann das Paket erstellt werden, aber es kann nicht geladen werden, sagen:

g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/home/renkun/R/x86_64-pc-linux-gnu-library/3.4/Rcpp/include" -I/home/renkun/bin/BarraOptimizer8.5/include -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c RcppExports.cpp -o RcppExports.o 
** libs 
g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/home/renkun/R/x86_64-pc-linux-gnu-library/3.4/Rcpp/include" -I/home/renkun/bin/BarraOptimizer8.5/include -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c barraopt.cpp -o barraopt.o 
g++ -std=gnu++11 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o barraopt.so RcppExports.o barraopt.o -L/home/renkun/bin/BarraOptimizer8.5/lib/intel64 -Wl,-R,/home/renkun/bin/BarraOptimizer8.5/lib/intel64 -lbarraopt -L/usr/lib/R/lib -lR 
installing to /tmp/Rtmpvbb6Io/devtools_install_42a342a07f84/barraopt/libs 
* DONE (barraopt) 
Error in dyn.load(dllfile) : 
    unable to load shared object '/home/renkun/Workspaces/barraopt/src/barraopt.so': 
    liboptsrvr.so: cannot open shared object file: No such file or directory 
Calls: suppressPackageStartupMessages ... <Anonymous> -> load_all -> load_dll -> library.dynam2 -> dyn.load 
Execution halted 

Exited with status 1. 

Es scheint, dass -Wl,-rpath hier nicht wirksam ist.

Unter einer Maschine mit Ubuntu 16.04 zeigt ldd src/barraopt.so, dass alle dynamische Verknüpfung behoben ist. (BARRA_OPS_HOME = /home/ken/bin/BarraOptimizer8.5)

linux-vdso.so.1 => (0x00007ffc89a16000) 
libbarraopt.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libbarraopt.so (0x00007f85dae49000) 
libimf.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libimf.so (0x00007f85da97f000) 
libR.so => /usr/lib/libR.so (0x00007f85da346000) 
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f85d9fc4000) 
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f85d9dae000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f85d99e3000) 
liboptsrvr.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/liboptsrvr.so (0x00007f85d7b10000) 
libopsproto.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libopsproto.so (0x00007f85d77a1000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f85d7497000) 
libintlc.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libintlc.so.5 (0x00007f85d7249000) 
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f85d6fe8000) 
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f85d6da1000) 
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f85d6b31000) 
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f85d690f000) 
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f85d66fe000) 
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f85d64e4000) 
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f85d62dc000) 
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f85d60d7000) 
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f85d5eb5000) 
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f85d5c98000) 
/lib64/ld-linux-x86-64.so.2 (0x000055fb75088000) 
libifcore.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libifcore.so.5 (0x00007f85d5961000) 
libifport.so.5 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libifport.so.5 (0x00007f85d5732000) 
libsvml.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libsvml.so (0x00007f85d4e6d000) 
libmosek64.so.7.0 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libmosek64.so.7.0 (0x00007f85d3c63000) 
libiomp5.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libiomp5.so (0x00007f85d396b000) 
libprotobuf.so.6 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libprotobuf.so.6 (0x00007f85d3668000) 
libbridge_common.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libbridge_common.so (0x00007f85d3417000) 
libsharc_xmlxproto.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libsharc_xmlxproto.so (0x00007f85d31a4000) 
libboost_thread.so.1.49.0 => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libboost_thread.so.1.49.0 (0x00007f85d2f8a000) 
libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f85d0ef5000) 
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f85d0ccc000) 
libxerces-c-3.1.so => /home/ken/bin/BarraOptimizer8.5/lib/intel64/libxerces-c-3.1.so (0x00007f85d07c4000) 
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f85d0499000) 
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f85d027f000) 
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f85d0040000) 

jedoch mit der gleichen Quelle, unter Ubuntu 17.10, zeigt ldd, dass die gemeinsam genutzte Objekte libbarraopt.so Links gegen nicht aufgehoben, obwohl -Wl,-rpath behoben ist secified: (BARRA_OPS_HOME = /home/renkun/bin/BarraOptimizer8.5)

linux-vdso.so.1 => (0x00007ffe067f5000) 
libbarraopt.so => /home/renkun/bin/BarraOptimizer8.5/lib/intel64/libbarraopt.so (0x00007f3dc5f0c000) 
libR.so => /usr/lib/libR.so (0x00007f3dc58e4000) 
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3dc555e000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3dc5208000) 
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3dc4ff1000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3dc4c11000) 
liboptsrvr.so => not found 
libopsproto.so => not found 
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f3dc49b6000) 
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f3dc4770000) 
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f3dc44fe000) 
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3dc42d8000) 
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3dc40c8000) 
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3dc3eab000) 
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3dc3ca3000) 
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3dc3a9f000) 
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f3dc3870000) 
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3dc3651000) 
/lib64/ld-linux-x86-64.so.2 (0x00007f3dc6526000) 
libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f3dc13ab000) 
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f3dc1182000) 
libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f3dc0da3000) 
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f3dc0b63000) 

Es sieht aus wie nur libbarraopt.so ist mit dem richtigen Pfad verknüpft, aber gemeinsame Objekte, gegen die es verknüpft, fehlen.

Ich frage mich, was könnte falsch sein mit meinen Build-Konfigurationen, die unter der Toolchain bricht durch 17.10 versendet. Obwohl globale Konfiguration wie ldconfig dieses Problem lösen würde, bevorzuge ich nicht, weil einige .so es sich auf einen Konflikt mit der Version des OS Schiffe verlässt. Ich würde lieber eine lokal konfigurierte Version verwenden, ohne die globale Konfiguration zu beeinflussen.

Answer 1

Es scheint, dass -Wl, -rpath hier nicht wirksam ist.

Was wahrscheinlich passiert ist, dass die aktualisierte Linker DT_RUNPATH dynamischen Tag, wo der alte Linker DT_RPATH emittieren emittiert. (Es ist auch möglich, dass Ihr alter Linker GNU-ld war und der neue Link Gold.)

Der DT_RUNPATH wird als korrekter bevorzugt und betrifft den Suchpfad der Binärdatei selbst, aber nicht der abhängigen Bibliotheken .

Die DT_RPATH hat einen globalen Effekt, ähnlich dem Hinzufügen des Verzeichnisses zu LD_LIBRARY_PATH Umgebungsvariablen.

Sie können dies überprüfen mit: readelf -d a.out | grep 'R.*PATH'.

Wenn Sie den RPATH gegen RUNPATH Unterschied tun sehen, und in der Tat werden mit Gold, können Sie das „alte“ Verhalten zwingen, mit -Wl,--disable-new-dtags (GNU ld auch hatte --disable-new-dtags es vor kurzem hinzugefügt, so dass es für entweder Linker funktionieren soll) .