build of cantor_rserver results in a broken executable

Křištof Želechovski yecril71pl at gmail.com
Wed Mar 21 18:16:57 UTC 2012


The following commands are used to build the executable cantor_rserver:

Linking CXX executable cantor_rserver
cd /home/abuild/rpmbuild/BUILD/cantor-4.7.2/build/src/backends/R/rserver && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/cantor_rserver.dir/link.txt --
verbose=1
/usr/bin/c++   -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-
protector -funwind-tables -fasynchronous-unwind-tables -g  -Wnon-virtual-dtor 
-Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -
Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-
check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -
fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -
DNDEBUG -DQT_NO_DEBUG  -Wl,--enable-new-dtags  -Wl,-Bsymbolic-functions  
CMakeFiles/cantor_rserver.dir/cantor_rserver_automoc.o 
CMakeFiles/cantor_rserver.dir/rserver.o 
CMakeFiles/cantor_rserver.dir/rcallbacks.o 
CMakeFiles/cantor_rserver.dir/main.o CMakeFiles/cantor_rserver.dir/settings.o 
CMakeFiles/cantor_rserver.dir/radaptor.o  -o cantor_rserver -rdynamic -
L/usr/lib64/R/lib -L/home/abuild/rpmbuild/BUILD/cantor-4.7.2/build/lib 
/usr/lib64/libkdeui.so.5.7.0 ../../../../lib/libcantorlibs.so.0.0.2 -lR -
lRlapack -lgfortran -lRblas /usr/lib64/libkio.so.5.7.0 
/usr/lib64/libQtNetwork.so /usr/lib64/libQtXml.so /usr/lib64/libkdeui.so.5.7.0 
/usr/lib64/libQtGui.so /usr/lib64/libQtSvg.so /usr/lib64/libkdecore.so.5.7.0 
/usr/lib64/libQtDBus.so /usr/lib64/libQtCore.so -lpthread 
/usr/bin/cmake -E cmake_progress_report 
/home/abuild/rpmbuild/BUILD/cantor-4.7.2/build/CMakeFiles 46

The result of the build is broken and fails to execute:

/usr/bin/cantor_rserver: error while loading shared libraries: libR.so: cannot 
open shared object file: No such file or directory

Here is the important part of the build command:

/usr/bin/c++   -L/usr/lib64/R/lib -lR -lRblas 

The input -lRblas should be implicit and pulled by -lR, as evidenced by the 
following error message when -lRblas is not explicitly specified: 

libRblas.so, needed by /usr/lib64/R/lib/libR.so, not found 
(try using -rpath or -rpath-link)

and specifying it explicitly can be only construed as a workaround.  However, 
it is a harmful workaround; it causes the build to formally succeed but the 
resulting executable is bro-ken.

A workaround: 

{ export LD_RUN_PATH=/usr/lib64/R/lib && g++ "-L$LD_RUN_PATH" -lR; }

According to the documentation, this workaround is not needed for Solaris 
because the -L option the right thing there :-)

What do you think?

Chris





More information about the Kde-buildsystem mailing list