[Rcpp-devel] unable to load shared object - Symbol not found

[Ismail SEZEN]

> 
> Not exactly "minimally reproducible".  Do tell beforehand than cloning the
> repo will suck down 300+ megabytes. And that you have build requirements for
> other packages exotic enough that they are NOT met by the reverse depends of
> the now almost 1100 packages I test against. Not nice.  And after I wasted
> all that time it STILL failed because you have an unsatisfiable depends in
> 'rwind'.  Did you mean rWind?

I really have to fill the page with apologies. Please, forgive me for the trouble. I feel like I've been beaten to death whenever I get an answer from Dirk :) But I’m ok with this. This makes me think twice before sending an email before. You are right. Next question WILL definetely have a minimally reproducible example. I also understood that I need to decrease the number of packages that the package depends on.

> Lastly, and regarding the warning of being unable to parse your 'Infinity'
> argument, we have had the following segment in Section 2.2 of the vignette
> 'Rcpp Attributes' for years:
> 
> Not all \proglang{C++} default argument values can be parsed into their
> \proglang{R} equivalents, however the most common cases are supported, including:
> 
>  Not all C++ default argument values can be parsed into their R equivalents, however
>  the most common cases are supported, including:
>  • String literals delimited by quotes (e.g. "foo")
>  • Decimal numeric values (e.g. 10 or 4.5)
>  • Pre-defined constants including true, false, R_NilValue, NA_STRING, NA_INTEGER,
>  NA_REAL, and NA_LOGICAL.
>  • Selected vector types (CharacterVector, IntegerVector, and NumericVector) instantiated
>  using the ::create static member function.
>  • Matrix types instantiated using the rows, cols constructor.
> 
> So your use case was out of scope.  You could set the default to NA_REAL and
> then (conditionally) replace that value inside the function.

I really thank you for the extra deep investigation and comments. I was aware of the warnings but ignored them for a while. I need to make a balance between writing pretty code and main research progress. That’s why the code and design are messy for now. I hope to publish it on CRAN when it is mature enough.

> 
> One of your other problems is that you mix twenty-eight generated function
> interfaces (via the Rcpp::exports() tag, the recommended approach) with the
> very old-school approach of two remaining manual .Call() in your R/hef.R.
> 
> That conflicts with us now using underscores, as the symbol name still used
> by you in .Call() now also needs the underscore.
> 
> That is not a battle we can win: either we try to help everybody by 'hiding'
> unexported symbols by prefixing with an underscore, or allow random mixing of
> Rcpp Attributes with .Call.  I prefer the former.

This was the source of error I figured out an half hour after I sent the e-mail (Silly me!). You are making a great package to integrate C++ easily into R which is a complex task. This tempts people (who know or don’t know C++) to use C++ in their projects and we moslty solve the issues searching by google but it does not always give the best approach to the problem even if I try to find newest ones. I always try to follow and use latest updates but this kind of old approaches might remain in the code.


> 
> Thanks for the report though.  But next time, __please__ try to submit
> something __minimally reproducible__ and not a blob requiring the
> installation of 15 other packages and a download of 300mb.

I thank you for your help and apology for the trouble again. 

best wishes,

Ismail SEZEN