2012/3/25 Pavel Heimlich, a.k.a. hajma <[email protected]>: > 2012/3/21 Křištof Želechovski <[email protected]>: >> 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. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
