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

Tue Jan 4 18:58:16 CET 2011

On 4 January 2011 at 18:24, Rainer Hurling wrote:
| On 04.01.2011 14:04 (UTC+1), Dirk Eddelbuettel wrote:
| >
| > On 4 January 2011 at 12:02, Rainer Hurling wrote:
| > | On 03.01.2011 13:20 (UTC+1), Dirk Eddelbuettel wrote:
| > |>  Rainer,
| > |>
| > |>  Please use the rcpp-devel list for questions. You need to subscribe to post,
| > |>  or you can use a web-to-list interface to gmane.org.
| > |
| > | Done. Hope it is ok to pursue the private thread on the list.
| >
| > That's perfect.
| >
| > |>  | It seems that 'src/Makevars' is not fully compatible to FreeBSD style
| > |>
| > |>  Hm. Can you try enforcing GNU make via something like
| > |>
| > |>          export MAKE=/usr/bin/gmake
| > |
| > | Thanks for the tip. With gmake it proceeds build and installing. But
| >
| > Good. We are actually trying to not depend on GNU make so you found an
| > infelicity which I may correct by ...
| 
| Nice.

That is now taken care of in SVN.

| > | there is another problem with testing the installation, see below please.
| > |
| > |>  (or whererever it it stored on your system). At that point the implicit
| > |>  variable $^ is used:
| > |>
| > |>  		$(SHLIB_CXXLD) -o $(USERLIB) $^ $(SHLIB_CXXLDFLAGS) $(ALL_LIBS)
| > |>
| > |>  Here $^ expands to the list of all prerequisites, so you could try $OBJECTS
| > |>  in its place.
| > |
| > | gmake is able to use $^, so there is no need for me to use $OBJECTS  :-)
| >
| > ... switching to $OBJECT in place of $^ here.
| >
| > | 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.
| 
| There is no /usr/lib64/R/lib on FreeBSD, instead it is located under 
| /usr/local/lib/R/lib.
| 
| > Odd. Is your R version built as a shared library?
| 
| I think so but I am not sure. Is there any quick test?

Yes. Look if your /usr/local/lib/R/lib contains what on my system is called libR.so.
I suspect it doesn't.

Did you build your own binary?  Did you use '--enable-R-shlib' ?   

This isn't needed for Rcpp but definitely needed for things like RInside or
other embedded uses of R.  It also makes everything linking with R a lot
smaller.

| > | 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' :
| 
| Ok, I see. I will answer some more about backtrace_symbol in my next 
| posting ...
| 
| > 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);
| > [...]
| >
| > | I tried to comment out the complete part between '#if defined(__GNUC__)'
| > | and '#endif' and use only
| > |
| > |      SEXP stack_trace( const char *file, int line) {
| > |          return R_NilValue ;
| > |      }
| > |
| > | That gives no more undefined symbols when loading, but of course there
| > | is no debugging code any more :-(
| > |
| > | Do you have any idea how to get debugging.cpp functional on FreeBSD?
| >
| > Well, not to put too fine a point on it: that's your job.  Your operating
| > system choice, your need.  We may give you the Windows behaviour (ie no
| > debugging trace) so that this builds on your system but we have no access to
| > *BSD and no particular desire to add this feature.  If you only want to run
| > parser and highlight (as per your first mail) then you do not need more.
| 
| Until now I have no need for the debugging functionality. That depends 
| on packages which will need it.

None AFAIK.  This is mostly an exotic debugging aide for us.

And I think the simplest may be to just treat FreeBSD like Windows here and
not support the feature.  I have no great interest in re-adding a configure
script just to support this corner case on your operating system which, by
all accounts, is not all that frequently employed by Rcpp users.

So we will probably add a #define to switch to disabling this along with a
comment in src/Makevars about how to re-enable it.  So you'd get it to work
if you can edit a single file.  Sounds fair enough to me.  

That is if and when we here from you that adding -lexecinfo helps or whether
you encounter other hurdles.

Cheers, Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com