[Rcpp-devel] RcppOctave on Windows: testing needed
Dominick Samperi
djsamperi at gmail.com
Tue Oct 8 19:36:25 CEST 2013
Nice. This might be called "meta-linking." One problem that linkers solve
for C++ is that
the same function may be defined more than once (because more than one
source file
may include the header containing the definition). What happens is that
weak defs are
written to the object files, and the linker removes the multiple defs and
does not
complain about multiple definitions. This does not seem to be necessary with
meta-linking.
On Tue, Oct 8, 2013 at 11:30 AM, Romain Francois
<romain at r-enthusiasts.com>wrote:
> Le 08/10/13 17:12, Dominick Samperi a écrit :
>
> 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).
>>
>
> Sure. There is always the issue of linking against R, etc ... but this
> would eliminate the need for linking against Rcpp.
>
> As for placing the client package in headers, not everything has to go
> there, I have e.g. some functions in Rcpp11 that are only defined in
> Rcpp11's .cpp file.
>
> For example:
>
> const char * type2name__impl(int sexp_type);
>
> What I've done is making it so that Rcpp11's headers calls this one
> instead:
>
> inline const char* type2name(int sexp_type){
> GET_CALLABLE(type2name__impl, sexp_type)
> }
>
> and all the magic is in the GET_CALLABLE macro:
>
> #if defined(COMPILING_RCPP11)
> #define GET_CALLABLE(__FUN__, ...) return __FUN__( __VA_ARGS__ ) ;
> #else
> #define GET_CALLABLE(__FUN__, ...) \
> typedef decltype(__FUN__)* Fun ; \
> static Fun fun = (Fun)R_GetCCallable( "Rcpp11", #__FUN__) ; \
> return fun(__VA_ARGS__) ;
> #endif
>
> So if we are compiling Rcpp11 (which is true only for .cpp files in
> Rcpp11), then type2name would directly call type2name__impl, otherwise we
> first get the function pointer with :
>
> static Fun fun = (Fun)R_GetCCallable( "Rcpp11", "type2name__impl" ) ;
>
> and then call fun.
>
> Writing this, I do realize that this in fact uses some C++11 features:
> variadic macros and decltype. It does not mean we could not do it in Rcpp,
> but it would be harder and would involve macro bloat (we would need
> something like GET_CALLABLE_0, GET_CALLABLE_1, GET_CALLABLE_2, ...
>
> Then, when Rcpp11 dynamic library is loaded by R, the __impl function is
> registered:
>
> #define REGISTER(__FUN__) R_RegisterCCallable( "Rcpp11", #__FUN__
> "__impl", (DL_FUNC)__FUN__ ## __impl );
>
> REGISTER(type2name)
>
> This allows me to have all in headers and use R's mechanism for "linking".
> Not really linking as it just involves resolving the function pointer.
>
> I find this more maintainable than depending on each platform's linker.
>
> Anyway, just saying a client package could use something similar so that
> it does not have to actually link.
>
> Romain
>
> On Tue, Oct 8, 2013 at 9:58 AM, Romain Francois
>> <romain at r-enthusiasts.com <mailto:romain at r-enthusiasts.**com<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>
>> <mailto: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
>> <mailto:renaud at mancala.cbio.**uct.ac.za<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>
>> '
>>
>> <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 <mailto: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
>> <mailto:renaud at mancala.cbio.**uct.ac.za<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131008/a2a21dda/attachment-0001.html>
More information about the Rcpp-devel
mailing list