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

[Rainer Hurling]

On 04.01.2011 18:58 (UTC+1), Dirk Eddelbuettel wrote:
> 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.

Wow, that is fast.

> |>  | 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.

You are right. There are only libRblas.so and libRlapack.so.

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

Yes, own binary build. No, my configure is like

./configure --with-blas="-lf77blas -latlas" --with-lapack="-lalapack 
-lcblas" --with-system-pcre --enable-threads=posix

> 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.

That sounds good.

> 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 really fair.

> That is if and when we here from you that adding -lexecinfo helps or whether
> you encounter other hurdles.
>
> Cheers, Dirk
>
> |>  Otherwise, Romain may of course be available for contracting.  If you or
> |>  someone else needs this feature on what happens to be a non-standard
> |>  platform, you may have to provide the (financial) resources to make it
> |>  happen.
> |>
> |>  Cheers, Dirk

Thanks again,
Rainer