Le 02/11/2013 09:35, Simon Zehnder a écrit :
First, I didn’t. But for getting some output from the functions in
attributes.cpp I later compiled the Rcpp package from source. When I compile
with the option “-headerpad_max_install_names” the compileAttributes runs
without an error. If I compile
Thanks Romain,
looks the same here. So the path is the same, but it seems, that the padding is
different. I would like to understand what happens when I call
compileAttributes. Is there anywhere a linking involved with Rcpp.so or
Rcpp.dylib?
Best
Simon
On 02 Nov 2013, at 09:57, Romain
compileAttributes ends up calling a .Call function that lives inside Rcpp.so.
Le 2 nov. 2013 à 10:25, Simon Zehnder szehn...@uni-bonn.de a écrit :
Thanks Romain,
looks the same here. So the path is the same, but it seems, that the padding
is different. I would like to understand what
Thanks Romain,
I’ll come back to this thread when I found out what the reason of this behavior
in my environment is.
Best
Simon
On 02 Nov 2013, at 10:46, Romain Francois rom...@r-enthusiasts.com wrote:
compileAttributes ends up calling a .Call function that lives inside Rcpp.so.
Le 2
Simon,
Here is what I would do:
1) See
http://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html
and learn about BOOSTLIB
2) Build a minimal R package invoking one or two Boost Thread functions.
Use BOOSTLIB in src/Makevars.win
3) Upload the package to win-builder. If
Jay,
Thank you.
Yeah, but as (
http://www.boost.org/doc/libs/1_54_0/more/getting_started/unix-variants.html#header-only-libraries
) said, Boost.Thread /must/ be built separately.
On 11/02/2013 11:07 PM, Jay Emerson wrote:
Simon,
If Boost.Thread is only headers, it would be a candidate to
