Yes, I also sporadically got this error. Don't know the origin, although it
may happen because Rtools is not in the path anymore: there may be some
conflict/mess up with dlls, which are present in Rtools and Octave, while
the package was compiled against Rtools ones. Possible or fantasy?
I updated both github and my CRAN repo, with a new version that has a
cleaner loading procedure.
I have just asked CRAN if they could install Octave on Win-builder so that
I can check the package on their Windows machine. On my box I am getting
strange errors when checking about not being able to read the DESCRIPTION
file... very weird.
Bests,
Renaud
On 8 October 2013 15:47, Dominick Samperi <djsamp...@gmail.com> wrote:
> 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 <geto...@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 <
>>> ren...@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'))
>>>> 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 <djsamp...@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 <
>>>>> ren...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
