<div dir="ltr"><div>That is interesting Romain, but the linking complexity remains<br>for derived packages like RcppOctave, and especially for derived<br>packages that export their C/C++ functions to clients (unless<br></div>
<div>these derived packages can also place all C++ code in header files).<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 8, 2013 at 9:58 AM, Romain Francois <span dir="ltr"><<a href="mailto:romain@r-enthusiasts.com" target="_blank">romain@r-enthusiasts.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I've only been following that thread from a distance. There is always so much I can do when it comes to windows.<br>
<br>
Anyway, in Rcpp11 I'm experimenting with completely letting go of the whole linking against the Rcpp library and all the issues it has brought to the table over the years (should it be static linking, how to call Rcpp:::LdFlags, need for a Makevars and a Makevars.win, ...).<br>
<br>
With Rcpp11, the only thing you'll ever need will be: LinkingTo: Rcpp11<br>
<br>
This was made possible by moving quite a big chunk of code into headers, and for the rest using the R mechanism (R_GetCCallable, R_RegisterCCallable) as described in WRE.<br>
<br>
Now, I have no idea yet if Rcpp11 works on windows. Right now I'm fearcely developping it, so I don't have time for playing games with windows. But that time will come.<br>
<br>
None of the techniques I'm using for that are depending on C++11, which would make it possible to use the same strategy for Rcpp too. But I fear that because too many depend on the current setting (Makevars, Makevars.win, making a library and non portably link against it) it is not likely to happen.<br>
<br>
Romain<br>
<br>
Le 08/10/13 15:47, Dominick Samperi a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I just installed the binary with Rtools not on my path (but with R in PATH)<br>
and the first time I tried to load/unload RcppOctave I got the obscure<br>
Windows load error (app terminated "in an unusual way"), but now I<br>
cannot reproduce it! If you are linking to the static Rcpp lib there<br>
should be no problems.<br>
<br>
I guess the source distribution is not in sync with the binary?<br>
<br>
<br>
On Tue, Oct 8, 2013 at 2:11 AM, Renaud <<a href="mailto:getoxxx@gmail.com" target="_blank">getoxxx@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:getoxxx@gmail.com" target="_blank">getoxxx@gmail.com</a>>> wrote:<br>
<br>
Good. Still wondering why path to Rcpp.dll is needed when installing<br>
the binary package since RcppOctave.dll is linked static to Rcpp.a<br>
with full path specified. Most users will use the binary and not<br>
build it from source (which requires Rtools and possibly more config.<br>
<br>
Did you try installing the binary directly from the repo (with only<br>
octave bin/ in the path, not Rtools nor R)?<br>
<br>
Renaud<br>
<br>
<br>
On Monday, October 7, 2013, Dominick Samperi wrote:<br>
<br>
I don't think you need to worry about linking against the .dll<br>
files, as the<br>
import libraries (.dll.a files) contain all of the information<br>
that the linker needs,<br>
and you PATH will tell Windows where to find the corresponding<br>
dll's.<br>
It is possible to link against the dll's without using import libs,<br>
but then various tricks have to be used to specify what is<br>
exported from each dll.<br>
<br>
I downloaded the source for 0.10.1 and it seems to build and install<br>
ok provided I place Rcpp.dll on PATH. It would save the user some<br>
trouble if PATH could be updated automatically, but it is<br>
probably not<br>
a good idea to have R package installation or startup update the<br>
users<br>
environment...<br>
<br>
<br>
<br>
On Mon, Oct 7, 2013 at 10:52 AM, Renaud Gaujoux<br>
<<a href="mailto:renaud@mancala.cbio.uct.ac.za" target="_blank">renaud@mancala.cbio.uct.ac.za</a><u></u>> wrote:<br>
<br>
Thanks for the details Dominick.<br>
I think I got it working now, by ad Octave bin directory to<br>
the path prior loading RcppOctave library.<br>
I tested it by renaming the Octave root directory into<br>
something different than at building time.<br>
<br>
I added the option to specify Octave path via option<br>
octave.path (e.g., see ?OctaveInit), so that the package<br>
loads fine even if Octave is not installed/found. The user<br>
can also define this option in the .Rprofile if Octave is<br>
not installed in the path by default.<br>
<br>
Please let me know if it works for you:<br>
<br>
install.packages('RcppOctave', repos = c(getOption('repos'),<br>
'<a href="http://web.cbio.uct.ac.za/~renaud/CRAN'" target="_blank">http://web.cbio.uct.ac.za/~<u></u>renaud/CRAN'</a>))<br>
library(RcppOctave)<br>
.O$rand()<br>
<br>
Note that this version (0.10.1) was linked against the<br>
.dll.a files, but will load the .dll files... I will try<br>
later to link against the .dll files as you suggested.<br>
<br>
Bests,<br>
Renaud<br>
<br>
<br>
<br>
On 7 October 2013 16:24, Dominick Samperi<br>
<<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>> wrote:<br>
<br>
Yes, I placed Octave bin on my path. This is required to<br>
find its dll's for the same reason<br>
that Rcpp libs (directory containing Rcpp.dll) needs to<br>
be on PATH. If you enable clients<br>
of RcppOctave.dll to link against functions provided by<br>
RcppOctave, then these clients<br>
will have to add the RcppOctave libs directory to their<br>
PATH.<br>
<br>
The Octave dll's must be in its bin directory due to<br>
another Windows dll search rule:<br>
when you run an executable (like octave.exe) that<br>
depends on dll's, Windows will<br>
resolve the dependencies when the dll's are in the same<br>
directory as the executable.<br>
<br>
You should be able to link to liboctave-1.dll using<br>
'-loctave-1', provided the bin<br>
directory is on your PATH. The gcc '.dll.a' suffix means<br>
the file is an import library,<br>
not a static lib or a shared lib. Import libs tell<br>
Windows how to resolve references<br>
in the corresponding dll. Windows uses the '.lib' suffix<br>
for import libs. For your<br>
purposes you should link against the dll's, not the dll.a's.<br>
<br>
<br>
<br>
On Mon, Oct 7, 2013 at 4:59 AM, Renaud Gaujoux<br>
<<a href="mailto:renaud@mancala.cbio.uct.ac.za" target="_blank">renaud@mancala.cbio.uct.ac.za</a><u></u>> wrote:<br>
<br>
Dominick, just to be sure: did you have Octave bin<br>
directory in your PATH when you tested the package?<br>
Because Octave dlls are also in that directory.<br>
<br>
I am getting confused on which path/dll is to be<br>
used where. Currently I build RcppOctave.dll linking<br>
against the dll.a files found in<br>
"C:\Octave\Octave3.6.4_gcc4.6.<u></u>2\lib\octave\3.6.4".<br>
But there are .dll files (although named<br>
liboctave-1.dll and not liboctave.dll as I would<br>
expect) in ""C:\Octave\Octave3.6.4_gcc4.<u></u>6.2\bin"<br>
where octave.exe. and octave-config.exe also live.<br>
I had tried loading the .dll.a files with dyn.load<br>
in R but got errors. The -1.dll files load fine, and<br>
might be the ones I could load manually in .onLoad.<br>
<br>
Now, should I also link using the bin/ path and the<br>
-1.dll files?<br>
<br>
Renaud<br>
</div></div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Romain Francois<br>
Professional R Enthusiast<br>
<a href="tel:%2B33%280%29%206%2028%2091%2030%2030" value="+33628913030" target="_blank">+33(0) 6 28 91 30 30</a></font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-<u></u>project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-<u></u>project.org/cgi-bin/mailman/<u></u>listinfo/rcpp-devel</a><br>
</div></div></blockquote></div><br></div>