[Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 10/10/13 18:16, Dirk Eddelbuettel a écrit :
>
> On 10 October 2013 at 18:02, Romain Francois wrote:
> | To give some context, I'm taking about using R's linking mechanism. I'm
> | talking about generating automatically the code that:
> | - registers a function with R_RegisterCCallable
> | - grabs the function with R_GetCCallable
>
> [...]
>
> | The name as given by nm definitely contains namespace information.
>
> You are making the heroic assumption that libraries are never stripped, this
> is something you have no control.  Eg each of the 100+ r-cran-* packages in
> Debian and Ubuntu will by default be stripped, leading to your approach to go
> belly-up:
>
> edd at max:~$ nm /usr/lib/R/site-library/tseries/libs/tseries.so
> nm: /usr/lib/R/site-library/tseries/libs/tseries.so: no symbols
> edd at max:~$
>
> "No symbols".
>
> This is a standard distro package a user may have:
>
> edd at max:~$ dpkg -S /usr/lib/R/site-library/tseries/libs/tseries.so
> r-cran-tseries: /usr/lib/R/site-library/tseries/libs/tseries.so
> edd at max:~$

Thank you for all that detailed information.

> So this approach can't be assumed to work _portably across compilers and os
> [distros]_ as I asked about earlier -- and which you chose to ignore.

Don't care.

> You can look at nm _on your box_ to learn about (unstripped) libraries.  But
> I would surmise that you cannot rely on this to build a tool chain.

It appears that either I'm not expressing myself clearly enough, or you 
don't understand what I'm saying or both.

The idea is that for a package "foo" I'm developping, I want to have a 
mechanism for finding patterned symbols in its so and act upon that 
information to generate some registration code to take advantage of R's 
linking mechanism.

For this I don't care about what symbols are exported in some other 
package in some distribution of some other os. It would just have to 
work for the person developping foo who sometimes has to regenerate the 
registration code.

It looks however that I can easily enough adapt attributes to handle a 
Rcpp::register attribute so that compileAttributes would also generate 
the registration code. So I don't need to use nm anyway.

I'll play with adding a Rcpp::register attribute in Rcpp11 and let you 
know about how I do it. But it does not seem people care about porting 
things I do in Rcpp11 back into Rcpp.

Anyway, as you said earlier, this thread is long enough.

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30