[Rcpp-devel] Build failures under windows 64 on R-forge?

[Douglas Bates]

By the way, we have gotten around this problem.  In one of the C++
classes I have some members that count iterations, etc. and declared
them as "unsigned int", being too smart for my own good it seems.
Apparently the compiler promoted them to long long int before trying
to wrap them.  Changing wrap(value) to wrap(int(value)) allowed us to
get it compiled.

On Wed, Jan 11, 2012 at 1:30 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 11 January 2012 at 13:03, Douglas Bates wrote:
> | On Wed, Jan 11, 2012 at 11:06 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
> | >
> | > On 9 January 2012 at 13:18, Douglas Bates wrote:
> | > | On Mon, Jan 9, 2012 at 12:50 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
> | > | > Just a guess. Try tossing either one at win-builder.
> | > |
> | > | I did throw lme4Eigen at win-builder.  Same errors.  I'll try RcppEigen.
> | >
> | > Did you get anywhere with this?  I am a bit pressed for time during the week
> | > but could possibly help one of the evenings, or maybe on the weekend.
> |
> | Not really.  Given that the problem seems to be from a wrap
> | instantiation, I was hoping that it could be made to go away by adding
> | a wrap specialization, similar to the specialization of as<int> to use
> | ::Rf_asInteger.  However, I haven't seen any changes by Romain
> | regarding the specialization of as so I would be guessing on how to do
> | the specialization of wrap.
>
> I think this is different. We have been over this a few times. If I remember
> correctly:
>
>   1)  Old g++ (up to 4.4 or so) treated C++ on this more loosely
>
>   2)  Newer g++ (4.5 ?, surely 4.6) complain about 'long long' as it is not
>       part of the C++1998 standard, only of C++2003.
>
>   3)  You only get C++2003 behaviour if you use -std=c++0x
>
>   4) CRAN treats -std=c++0x as non-portable so we cannot really use it at
>       the package level, and consequently, 'plain' Rcpp does not see 'long
>       long'.
>
>   5)  RcppCommon.h enables '#define RCPP_HAS_LONG_LONG_TYPES' if 4) is given
>       so the advice is to wrapp /all/ sections using 'long long' in
>       #ifdef RCPP_HAS_LONG_LONG_TYPES
>
> Still with me and not fallen asleep?
>
> Now, there had been a distinct issue with the introduction of int64 support
> in 0.9.8 which also removed long support, but that is a different issue and
> taken care of in Rcpp 0.9.9 (at the expense of int64 support, which
> presumably nobody but Google uses and I conjecture they have enough internal
> smarts to patch that locally until Romain comes up with a more generic fix).
>
> How to enable all this transparently on all compiler versions (back to g++
> 4.2.1 used on a family of machines originating in Cupertino, CA, ...) and
> word size (int is long on 64 bit but not on 32 bit) etc is a bit of a pain.
>
> Rcpp, I believe, currently gets it right.
>
> | Also, it is difficult to test it because it means changing Rcpp then
> | re-installing RcppEigen and lme4Eigen - not something that can be done
> | easily at win-builder.  That means creating a windows 64 build
> | environment under virtualbox or something like that.  At this point I
> | would prefer to wait to see if it sorts itself out.
>
> "L'espoir fait vivre" or hope springs eternal...
>
> | > It did look like the one of those "'long long' not know under C++2003". So I
> | > would have a look at what Rcpp does, try a three-liner function with Rcpp
> | > using a long long and go from there.
>
> I still recommend this, but I may as have missed something alltogether. Am a
> little undercaffeniated and underslept today ;-)
>
> Dirk
>
> | > Dirk
> | >
> | > --
> | > "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
> | > dark to read." -- Groucho Marx
>
> --
> "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
> dark to read." -- Groucho Marx