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
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to