build of cantor_rserver results in a broken executable

[Pavel Heimlich, a.k.a. hajma]

2012/3/21 Křištof Želechovski <yecril71pl at gmail.com>:
> 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

Hi Křištof,
I'm seeing something similar in my Solaris build (KDE 4.8.1 with
Studio 12.3 on Solaris 11).
Is your libR.so linked correctly? Mine seems broken, so I'm first
going to fix R:
$ ldd /opt/kde4/lib/R/lib/libR.so|grep not
        libRblas.so =>   (file not found)

regards
P.