[Rcpp-devel] RcppOctave on Windows: testing needed

Dominick Samperi 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:

> 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 <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)?
>>     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
>>         <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'),
>>             'http://web.cbio.uct.ac.za/~**renaud/CRAN'<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
>>             <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
>>                 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
>>                 <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
>>                     "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
> Rcpp-devel at lists.r-forge.r-**project.org<Rcpp-devel at lists.r-forge.r-project.org>
> https://lists.r-forge.r-**project.org/cgi-bin/mailman/**
> listinfo/rcpp-devel<https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131008/94f36cb8/attachment-0001.html>

More information about the Rcpp-devel mailing list