[Rcpp-devel] Defining template specialisation for wrap on Windows 64bit (Compilation error: 'result_type' does not name a type)

Some follow up on this issue.
RcppOctave ships an Octave module that call R own RNG functions, and
hence need to be compiled against R libraries. The compilation works
fine on both Linux and Windows (see details below). Note that using
R_NO_REMAP here really does not make a difference, but I still use it
just in case. So R and Octave headers are happy together.

The error really happens at the line where Rccp.h is included, not
when including RcppCommon.h, nor when declaring the wrap
specialisation. This is maybe something specific to templates? Are
these known to be handled differently in Windows and Linux (in
general, not specifically Rcpp)?

Renaud


##############
The includes for this module are declared as follows:

// Octave includes
#include <octave/config.h>
#include <octave/oct-obj.h>
#include <octave/oct-map.h>
#include <octave/defun-dld.h>

// STD includes
#include <limits.h>

#define R_NO_REMAP
#include <Rmath.h>
#include <R_ext/Random.h>

The compilation and linking are performed via mkoctfile, only adding
includes and lib directives to R stuff, as follows:

$ mkoctfile -v -IC:/R/R-3.0.2/include -IC:/R/R-3.0.2/include/i386
-LC:/R/R-3.0.2/bin/i386 -lR -lR  Rrng.cc

g++ -shared-libgcc -c -I/c/OctaveB/gplibs/include
-I/c/OctaveB/OctaveLibs/include -I/c/OctaveB/GnuWin32/include
-IC:\Octave\Octave3.6.4_gcc4.6.2\include\octave-3.6.4\octave\..
-IC:\Octave\Octave3.6.4_gcc4.6.2\include\octave-3.6.4\octave
-IC:\Octave\Octave3.6.4_gcc4.6.2\include -mieee-fp
-IC:/OctaveB/gplibs/include/freetype2 -IC:/OctaveB/gplibs/include
-IC:/OctaveB/gplibs/include   -g -O2   -IC:/R/R-3.0.2/include
-IC:/R/R-3.0.2/include/i386  Rrng.cc -o Rrng.o

g++ -shared-libgcc -shared -Wl,--export-all-symbols
-Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc  -o
Rrng.oct  Rrng.o   -LC:/R/R-3.0.2/bin/i386 -lR -lR
-LC:\Octave\Octave3.6.4_gcc4.6.2\lib\octave\3.6.4
-LC:\Octave\Octave3.6.4_gcc4.6.2\lib -loctinterp -loctave -lcruft

Yay! Three cheers!

Indeed wouldn't it be nice to get it working on windows uh? I had a
number of queries for this recently...

I'd simplify first. Try smaller example on Windows not involving Octave
headers.

Yes, sorry I did not mentioned this. This is definitely linked with
Octave. I did try defining a wrap specialisation without Octave and it
worked fine, so no issues on your side :)

So the question would rather be: has anybody experienced such error
when defining specialisation to third-party classes, for which one
does not control includes, defines, etc...?