build of cantor_rserver results in a broken executable

Pavel Heimlich, a.k.a. hajma tropikhajma at gmail.com
Sun Mar 25 23:58:22 UTC 2012


2012/3/25 Pavel Heimlich, a.k.a. hajma <tropikhajma at gmail.com>:
> 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)

I had to add '-R/opt/kde4/lib/R/lib' (this is where libR.so lives) to
my LDFLAGS.
But our build env. is a bit special so this is not necessarily a fault
of the kde build system.


More information about the Kde-buildsystem mailing list