[Rcpp-devel] RcppOctave on Windows: testing needed

Wed Oct 9 07:34:45 CEST 2013

I tried to build RcppOctave under Mac OS X (10.8.5) but ran into
a few problems.

1. In src/modules/Makefile.in, the '-F' flag (for framework) is not
    recognized by mkoctfile, so I added this temporary work-around:

#R_LDFLAGS = @R_LDFLAGS@
R_LDFLAGS = -L/Library/Frameworks/R.framework/Libraries -lR

2. Parsing the man files o_whatever.Rd fails (attempt to
    free an unallocated pointer), so I removed all of these
    man pages for now (the failure occurs in
   <R>/src/library/tools/R/Rd.R, function .build_Rd_db(),
   where .fetch_Rd_object is applied to each Rd file).

3. With these changes the build gets to the point where
    the install process checks if the package can be
    loaded, and fails with:

** testing if installed package can be loaded
sh: line 1: 55395 Abort trap: 6
'/Library/Frameworks/R.framework/Resources/bin/R' --no-save --slave 2>&1 <
'/var/folders/fq/2th4vc9n1mq9cxv5nl9bmzkc0000gn/T//RtmpbjkEA7/filed5d471d0dd21'
R(55395) malloc: *** error for object 0x7fff7684d570: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug
ERROR: loading failed
* removing ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’
* restoring previous ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’

4. If I ignore this and try to run library(RcppOctave) in R I get:

> library(RcppOctave)
Loading required package: Rcpp
Loading required package: pkgmaker
Loading required package: registry
R(55403) malloc: *** error for object 0x7fff7684d570: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

5. Setting the breakpoint as instructed was not very helpful
as the malloc code does not have symbols and cannot be
traced.

On Tue, Oct 8, 2013 at 10:27 AM, Renaud Gaujoux <
renaud at mancala.cbio.uct.ac.za> wrote:

> 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 <djsamperi at 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 <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'))
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131009/d00a6773/attachment-0001.html>