[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