[Rcpp-devel] Rcpp_0.9.0.tar.gz does not build on FreeBSD

[Rainer Hurling]

On 04.01.2011 18:58 (UTC+1), Romain Francois wrote:
> Le 04/01/11 18:51, Rainer Hurling a écrit :
>> On 04.01.2011 16:58 (UTC+1), Dirk Eddelbuettel wrote:
>>> On 4 January 2011 at 07:04, Dirk Eddelbuettel wrote:
>>> | On 4 January 2011 at 12:02, Rainer Hurling wrote:
>>> | | On 03.01.2011 13:20 (UTC+1), Dirk Eddelbuettel wrote:
>>> | | As mentioned above build and install are successfull. But testing if
>>> | | installed package can be loaded fails:
>>> | |
>>> | | -------------------------------------------
>>> | | [..SNIP..]
>>> | | g++ -shared -L/usr/local/lib -o Rcpp.so Date.o DateVector.o
>>> Datetime.o
>>> | | DatetimeVector.o Dimension.o DottedPair.o Environment.o Evaluator.o
>>> | | Formula.o Function.o Language.o Module.o Pairlist.o Promise.o
>>> RObject.o
>>> | | RcppCommon.o Rcpp_init.o Reference.o S4.o Symbol.o WeakReference.o
>>> | | barrier.o cache.o coerce.o complex.o debugging.o exceptions.o
>>> posixt.o
>>> | | r_cast.o
>>> |
>>> | This line should have -L/usr/lib64/R/lib -lR at the end.
>>> |
>>> | Odd. Is your R version built as a shared library?
>>> |
>>> | | g++ -o libRcpp.so Date.o DateVector.o Datetime.o DatetimeVector.o
>>> | | Dimension.o DottedPair.o Environment.o Evaluator.o Formula.o
>>> Function.o
>>> | | Language.o Module.o Pairlist.o Promise.o RObject.o RcppCommon.o
>>> | | Rcpp_init.o Reference.o S4.o Symbol.o WeakReference.o barrier.o
>>> cache.o
>>> | | coerce.o complex.o debugging.o exceptions.o posixt.o r_cast.o
>>> -shared
>>> |
>>> | Dito here.
>>> |
>>> | | ar qc libRcpp.a Date.o DateVector.o Datetime.o DatetimeVector.o
>>> | | Dimension.o DottedPair.o Environment.o Evaluator.o Formula.o
>>> Function.o
>>> | | Language.o Module.o Pairlist.o Promise.o RObject.o RcppCommon.o
>>> | | Rcpp_init.o Reference.o S4.o Symbol.o WeakReference.o barrier.o
>>> cache.o
>>> | | coerce.o complex.o debugging.o exceptions.o posixt.o r_cast.o
>>> | | cp libRcpp.so ../inst/lib
>>> | | cp libRcpp.a ../inst/lib
>>> | | rm libRcpp.so libRcpp.a
>>> | | installiert nach /usr/local/lib/R/library/Rcpp/libs
>>> | | ** R
>>> | | ** inst
>>> | | ** preparing package for lazy loading
>>> | | ** help
>>> | | *** installing help indices
>>> | | ** building package indices ...
>>> | | ** testing if installed package can be loaded
>>> | | Error in dyn.load(file, DLLpath = DLLpath, ...) :
>>> | | kann shared object '/usr/local/lib/R/library/Rcpp/libs/Rcpp.so'
>>> nicht
>>> | | laden:
>>> | | /usr/local/lib/R/library/Rcpp/libs/Rcpp.so: Undefined symbol
>>> | | "backtrace_symbols"
>>> | | Fehler: loading failed
>>> | | * removing '/usr/local/lib/R/library/Rcpp'
>>> | | -------------------------------------------
>>> | |
>>> | | I do not understand why 'backtrace_symbols' is undefined. In
>>> | | 'src/debugging.cpp' all seems to be ok?
>>> |
>>> | No, it is a system library function we use. From 'man
>>> backtrace_symbol' :
>>> |
>>> | BACKTRACE(3) Linux Programmer's Manual BACKTRACE(3)
>>> |
>>> | NAME
>>> | backtrace, backtrace_symbols, backtrace_symbols_fd - support for
>>> application self-
>>> | debugging
>>> |
>>> | SYNOPSIS
>>> | #include<execinfo.h>
>>> |
>>> | int backtrace(void **buffer, int size);
>>> |
>>> | char **backtrace_symbols(void *const *buffer, int size);
>>> |
>>> | void backtrace_symbols_fd(void *const *buffer, int size, int fd);
>>> | [...]
>>>
>>> A quick Google search for 'backtrace_symbols FreeBSD' points to a need
>>> for
>>> linking with -lexecinfo
>>
>> libexecinfo is not an internal libc function within FreeBSD. It has to
>> build as external so called port. On my system it is installed in
>> version 1.1.
>>
>> The ports info says:
>>
>> -------------------------------------------
>> I. About
>> This is a quick-n-dirty BSD licensed clone of backtrace facility found
>> in the GNU libc, mainly intended for porting linuxish code to BSD
>> platforms, however it can be used at any platform which has a gcc
>> compiler.
>>
>> More information about API can be found here:
>> http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
>>
>> II. Known limitations
>> - Depth of stack trace is limited to 128 levels, which should be enough
>> in most cases, the limit can be increased by editing gen.py and
>> regenerating stacktraverse.c. The reason for that limitation steams
>> from the fact that __builtin_return_address() function takes only
>> constant as an argument, while gcc(1) has problems compiling giant
>> switch() tables. For example to compile one with 1024 entries gcc(1)
>> needs more than 1GB of memory (sic!);
>> - executable have to be linked using `-Wl,--export-dynamic' option,
>> in order for function names to be displayed properly.
>>
>> III. Author
>> Author of this junk is Maxim Sobolev <sobomax at FreeBSD.org>. Any
>> feedback, patches or suggestions are greatly appreciated.
>> -------------------------------------------
>>
>>
>> The library is located under /usr/local/lib/libexecinfo.[so|a]
>>
>>
>> The header file is located under /usr/local/include/execinfo.h
>>
>> It defines 'backtrace_symbols' like this:
>>
>> #ifndef _EXECINFO_H_
>> #define _EXECINFO_H_
>>
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>>
>> int backtrace(void **, int);
>> char ** backtrace_symbols(void *const *, int);
>> void backtrace_symbols_fd(void *const *, int, int);
>>
>> #ifdef __cplusplus
>> }
>> #endif
>>
>> #endif /* _EXECINFO_H_ */
>>
>>
>>> Can you please modify src/Makevars at your end by adding this line right
>>> after the line containing PKG_CPPFLAGS:
>>>
>>> PKG_LIB += -lexecinfo
>>
>> Unfortunately this seems to be not enough. The same error occurs.
>>
>> I think as a workaround we should disable the debugging function under
>> FreeBSD. A suitable preprocessor define should be '__FreeBSD__'.
>>
>> What do you think?
>
> That's fair enough. The use of backtrace_symbols is somewhat of an
> underused black magic I once put in.
>
> We might drop this altogether as it is not used all that much.

Thanks for this solution. I already answered a little more detailed on 
the posting of Dirk.

> Romain
>
>> Rainer
>>
>>> Dirk