Hello,
I've only been following that thread from a distance. There is always so
much I can do when it comes to windows.
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, ...).
With Rcpp11, the only thing you'll ever need will be: LinkingTo: Rcpp11
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.
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.
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.
Romain
Le 08/10/13 15:47, Dominick Samperi a écrit :
I just installed the binary with Rtools not on my path (but with R in PATH)
and the first time I tried to load/unload RcppOctave I got the obscure
Windows load error (app terminated "in an unusual way"), but now I
cannot reproduce it! If you are linking to the static Rcpp lib there
should be no problems.
I guess the source distribution is not in sync with the binary?
On Tue, Oct 8, 2013 at 2:11 AM, Renaud <[email protected]
<mailto:[email protected]>> wrote:
Good. Still wondering why path to Rcpp.dll is needed when installing
the binary package since RcppOctave.dll is linked static to Rcpp.a
with full path specified. Most users will use the binary and not
build it from source (which requires Rtools and possibly more config.
Did you try installing the binary directly from the repo (with only
octave bin/ in the path, not Rtools nor R)?
Renaud
On Monday, October 7, 2013, Dominick Samperi wrote:
I don't think you need to worry about linking against the .dll
files, as the
import libraries (.dll.a files) contain all of the information
that the linker needs,
and you PATH will tell Windows where to find the corresponding
dll's.
It is possible to link against the dll's without using import libs,
but then various tricks have to be used to specify what is
exported from each dll.
I downloaded the source for 0.10.1 and it seems to build and install
ok provided I place Rcpp.dll on PATH. It would save the user some
trouble if PATH could be updated automatically, but it is
probably not
a good idea to have R package installation or startup update the
users
environment...
On Mon, Oct 7, 2013 at 10:52 AM, Renaud Gaujoux
<[email protected]> wrote:
Thanks for the details Dominick.
I think I got it working now, by ad Octave bin directory to
the path prior loading RcppOctave library.
I tested it by renaming the Octave root directory into
something different than at building time.
I added the option to specify Octave path via option
octave.path (e.g., see ?OctaveInit), so that the package
loads fine even if Octave is not installed/found. The user
can also define this option in the .Rprofile if Octave is
not installed in the path by default.
Please let me know if it works for you:
install.packages('RcppOctave', repos = c(getOption('repos'),
'http://web.cbio.uct.ac.za/~renaud/CRAN'))
library(RcppOctave)
.O$rand()
Note that this version (0.10.1) was linked against the
.dll.a files, but will load the .dll files... I will try
later to link against the .dll files as you suggested.
Bests,
Renaud
On 7 October 2013 16:24, Dominick Samperi
<[email protected]> wrote:
Yes, I placed Octave bin on my path. This is required to
find its dll's for the same reason
that Rcpp libs (directory containing Rcpp.dll) needs to
be on PATH. If you enable clients
of RcppOctave.dll to link against functions provided by
RcppOctave, then these clients
will have to add the RcppOctave libs directory to their
PATH.
The Octave dll's must be in its bin directory due to
another Windows dll search rule:
when you run an executable (like octave.exe) that
depends on dll's, Windows will
resolve the dependencies when the dll's are in the same
directory as the executable.
You should be able to link to liboctave-1.dll using
'-loctave-1', provided the bin
directory is on your PATH. The gcc '.dll.a' suffix means
the file is an import library,
not a static lib or a shared lib. Import libs tell
Windows how to resolve references
in the corresponding dll. Windows uses the '.lib' suffix
for import libs. For your
purposes you should link against the dll's, not the dll.a's.
On Mon, Oct 7, 2013 at 4:59 AM, Renaud Gaujoux
<[email protected]> wrote:
Dominick, just to be sure: did you have Octave bin
directory in your PATH when you tested the package?
Because Octave dlls are also in that directory.
I am getting confused on which path/dll is to be
used where. Currently I build RcppOctave.dll linking
against the dll.a files found in
"C:\Octave\Octave3.6.4_gcc4.6.2\lib\octave\3.6.4".
But there are .dll files (although named
liboctave-1.dll and not liboctave.dll as I would
expect) in ""C:\Octave\Octave3.6.4_gcc4.6.2\bin"
where octave.exe. and octave-config.exe also live.
I had tried loading the .dll.a files with dyn.load
in R but got errors. The -1.dll files load fine, and
might be the ones I could load manually in .onLoad.
Now, should I also link using the bin/ path and the
-1.dll files?
Renaud
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
