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

[Yan Zhou]

I think it at least confirms that this was indeed a problem related to building R.

I tried gcc -O0, same error happens, including the error when installing Rcpp.

Also I think you are right about the optimization thing. With -O2, the compiler see that p was never used and thus optimized the whole statement. Therefore when linking, there is no error at all (because clock_gettime was not referenced at all) and R happily conclude that clock_gettime was there with or without librt. To confirm this, try the following two program,

#include <time.h>
#include <stdio.h>

int main ()
{
    char *p = (char *) clock_gettime;
    printf("%c", *p);
}

Without the printf (just like conftest.c), then either gcc or clang complains undefined symbol with -O0 and silent when -O2. With the printf, which make the pointer actually used, with either gcc or clang, and whatever optimization level, the program won't compile unless -lrt.

I think the whole test of clock_gettime in R's configure.ac is flawed. It test first if clock_gettime exists by compiling an executable, which won't success unless -lrt or -O2. And only when it succeeded, it checks if clock_gettime is in librt. If -O0, then it will always fail because no -lrt was used in the first test and the test in librt was not performed at all. I guess the second line was meant to b
if test "${ac_cv_have_decl_clock_gettime}" = "no"; then
However I am not familiar with autotools, again.
With -O2, then the test succeed as long as clock_gettime was declared in the header.

 I think you shall report a bug to relevant R list.

Whether it is wise to having Rcpp link explicitly to librt is for Dirk and others to decide, considering this should be linked by R if it exists (I guess it is used for system.time etc)

Best,

Yan Zhou

> 
> ~/bin$ CC=clang CFLAGS=-g -O0 CXX=clang++ ~/src/R-devel/configure --enable-memory-profiling --enable-R-shlib --disable-byte-compiled-packages
> 
> Looking at R's config.log carefully, I eventually spotted a difference depending on compilation with -O0 (when the symbol is not found) and -O2 (when everything is fine). The essence of the test is
> 
> ~/tmp$ clang -O0 conftest.c
> /tmp/conftest-hn9uU6.o: In function `main':
> conftest.c:(.text+0x9): undefined reference to `clock_gettime'
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> ~/tmp$ clang -O2 conftest.c
> 
> for either gcc or clang, in R-2-15 or R-devel. conftest.c is, at the end of the day
> 
> #include <time.h>
> 
> int
> main ()
> {
> #ifndef clock_gettime
>  char *p = (char *) clock_gettime;
> #endif
> 
>  ;
>  return 0;
> }
> 
> with -O2 succeeding because, well, the 'check' is optimized out (right?). This is from R-devel/configure.ac:1835
> 
> R_CHECK_FUNCS([clock_gettime timespec_get], [#include <time.h>])
> if test "${ac_cv_have_decl_clock_gettime}" = "yes"; then
> AC_CHECK_LIB(rt, clock_gettime)
> fi
> 
> I'm not completely sure of this...
> 
> Martin
> 
>> 
>> 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
>> 
> 
> 
> -- 
> 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