[Rcpp-devel] RcppOctave on Windows: testing needed
djsamperi at gmail.com
Tue Oct 8 17:12:01 CEST 2013
That is interesting Romain, but the linking complexity remains
for derived packages like RcppOctave, and especially for derived
packages that export their C/C++ functions to clients (unless
these derived packages can also place all C++ code in header files).
On Tue, Oct 8, 2013 at 9:58 AM, Romain Francois <romain at r-enthusiasts.com>wrote:
> 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.
> 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
>> 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 <getoxxx at gmail.com
>> <mailto:getoxxx at gmail.com>> 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)?
>> 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
>> It is possible to link against the dll's without using import
>> 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
>> 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
>> On Mon, Oct 7, 2013 at 10:52 AM, Renaud Gaujoux
>> <renaud at mancala.cbio.uct.ac.za**> 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'),
>> 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.
>> On 7 October 2013 16:24, Dominick Samperi
>> <djsamperi at gmail.com> 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
>> 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
>> On Mon, Oct 7, 2013 at 4:59 AM, Renaud Gaujoux
>> <renaud at mancala.cbio.uct.ac.za**> 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
>> 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?
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-**project.org<Rcpp-devel at lists.r-forge.r-project.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rcpp-devel