[Rcpp-devel] undefined symbol: clock_gettime in Rcpp 0.10.2

[Yan Zhou]

Just a guess.

Is it possible that this is caused by the way how R was built? Since you are using clang and R unstable, it is clear that you build R yourself.

>From the error message, it happens when  "testing if installed package can be loaded" and trying to load Rcpp.so through dyn.load. I am not very sure how dyn.load works (and thus please ignore me if I am talking non-sense), but from the help page it seems that it loads additional shared object into the executing R image. On my machine, R was built as a shared library, and
ldd libR.so
shows among other things librt. In other words, librt was loaded when R was started. However building Rcpp only builds libraries rather than executables, and thus there shouldn't be errors when building Rcpp while loading Rcpp may cause errors unless librt was already loaded or linked to libRcpp.so

Another reason that I suspect that this is not a problem with compiler but how R is built is that, try the following program,

#include <time.h>

int main ()
{
    clock_gettime(0,0);
}

with either g++ or clang++, without explicit linking to -lrt, the same undefined symbol error occurs. For instance, on my RHEL, with g++ 4.4,
$ g++ -o foo foo.cpp 
/tmp/ccKB2Ftv.o: In function `main':
foo.cpp:(.text+0xf): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status

Change main to say, foo, and build a shared or static library without linking to librt causes no problems at all (though loading that library will cause problems as usual).

If so far what I am talking is not non-sense, then I suggest you find your libR.so library, and check if it indeed does not link to librt. If that is the case, we need to find out how to build R to trigger the linking to librt (build R with profiling, which is the default?)

Anyway, as Dirk said, linking to librt is harmless on Linux nonetheless, so that is perhaps the easiest 'fix'.

Best,

Yan Zhou

On Dec 24, 2012, at 1:11 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

> 
> On 23 December 2012 at 18:31, Martin Morgan wrote:
> | When trying to install Rcpp 0.10.2 with
> | 
> | $ R --version
> | R Under development (unstable) (2012-12-18 r61372) -- "Unsuffered Consequences"
> | $ clang++ --version
> | Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
> | Target: x86_64-pc-linux-gnu
> | Thread model: posix
> 
> I just upgraded my r-devel version today; the one I used to test 0.10.2 was
> probably a week or at the most two weeks old. I did quite a few R CMD check
> runs; they all passed -- but I only used g++.
> 
> Methinks I could have caught that if I had used clang.
> 
> | I get
> | 
> | $ R CMD INSTALL Rcpp_0.10.2.tar.gz
> | ...
> | clang++ -I/home/mtmorgan/bin/R-devel/include -DNDEBUG -I../inst/include/ 
> | -I/usr/local/include    -fpic  -g -O2  -c Timer.cpp -o Timer.o
> | ...
> | ** testing if installed package can be loaded
> | Error in dyn.load(file, DLLpath = DLLpath, ...) :
> |    unable to load shared object 
> | '/home/mtmorgan/R/x86_64-unknown-linux-gnu-library/2.16/Rcpp/libs/Rcpp.so':
> |    /home/mtmorgan/R/x86_64-unknown-linux-gnu-library/2.16/Rcpp/libs/Rcpp.so: 
> | undefined symbol: clock_gettime
> | Error: loading failed
> | 
> |  From man clock_gettime I have
> | 
> | ...
> |         Link with -lrt.
> | 
> | and adding PKG_LIBS += -lrt to src/Makevars addresses the problem for me, but 
> | I'm not sure that is a universal solution? Also, I had an identical problem with 
> | another package (Matrix, since corrected) so there is perhaps something 
> | a-typical about my configuration.
> 
> I don't think so. The internal-to-Rcpp Timer class is new in 0.10.2.  And Yan
> is (as usual) correct, -lrt is AFACR specific to Linux. I needed that in the
> past when using the kernel-based high-res timer.
> 
> So this is something we need to figure out. So we seem to know that r-devel
> and clang need it. Can you check if r-release needs it?  With g++, neither R
> versions seems to need it.  
> 
> OTOH I don't think adding -lrt does any harm so maybe we'll add "in general".
> Might run this by Simon too....  This needs more work.
> 
> Thanks so much for the heads-up!
> 
> Dirk
> 
> | 
> | Martin
> | -- 
> | Computational Biology / Fred Hutchinson Cancer Research Center
> | 1100 Fairview Ave. N.
> | PO Box 19024 Seattle, WA 98109
> | 
> | Location: Arnold Building M1 B861
> | Phone: (206) 667-2793
> | _______________________________________________
> | Rcpp-devel mailing list
> | Rcpp-devel at lists.r-forge.r-project.org
> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> 
> -- 
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com  
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel