On 6/24/2015 15:07, Ramon Diaz-Uriarte wrote:
Hi Matt,

Thanks a lot for the details and the work. That is great! There is a
problem, though: in my particular case, I am uploading my package to
BioConcutor, and there the compiler for Win is 4.6.3 so I am restricted to
that. Including randutils will lead to an error during building the package
in Windows.
Yeah, in this case I think replacing the source of entropy with something else may be the compromise choice (it's a range eventually passed to `mix_entropy`, so I'd investigate the effects on that). That all being in the meantime / while waiting for the toolchain to catch up, of course...

Best,

Matt

Best,

R.

On Wed, 24-06-2015, at 14:55, Matt D. <mat...@gmail.com> wrote:
On 6/22/2015 12:31, Ramon Diaz-Uriarte wrote:
Actually, I just noticed that things will not work if you need your package
to run on Windoze: Rtools uses gcc 4.6.3 there, and this will not work with
gcc 4.6 (neither in Linux nor Windows) with flag -std=c++0x or
-std=gnu++0x. I guess this should be fixable, but I do not know enough to
do it.
Hi again!

I've just tried with the work-in-progress, _experimental_ version
available at the following location:
https://rawgit.com/kevinushey/RToolsToolchainUpdate/master/mingwnotes.html

// In particular, I've used "Windows native compiler for 64 bit Windows
output mingw32mingw64_gcc-4.9.2.toolchain.tar.gz".

This works better -- the only missing part is <thread> support :-(
However, it is not exactly essential here, in that it's used solely in
one place -- to get some extra entropy; that's all.
After temporarily removing dependence on `std::this_thread::get_id()`,
the example -- available at
http://www.pcg-random.org/posts/ease-of-use-without-loss-of-power.html
-- compiles and runs successfully.

Incidentally,  one can get threads support for MinGW using MSYS2, which
gives:
Thread model: posix
gcc version 4.9.2 (Rev5, Built by MSYS2 project)

However, the MinGW that comes with Rtools uses the following:
Thread model: win32
gcc version 4.9.2 (GCC)

I presume there must be a reason for that. There are certainly
trade-offs present:
https://wiki.qt.io/MinGW-64-bit#GCC_Threading_model_.28posix_vs_win32.29
What hits us here is the "no C++11 <thread>, <mutex>, or <future> "
("C11" appears to be a typo) part for the win32 choice.
// See also:
https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32

Note that there's nothing multithreading-specific about the library, so
even though I've also tested it with
https://github.com/meganz/mingw-std-threads (warning: just something
I've ran across while searching for multithreading support for MinGW
built w/ win32 threading model, quality and license unknown) and also
made it compile & work after a small patch (adding the std::hash
specialization), it's probably possible to use another source of entropy
here.

I presume another idea would be to use a different GCC version, but
that's rather tedious --
https://stackoverflow.com/questions/25455829/using-a-different-gcc-version-from-that-included-with-rtools-with-rcpp-on-window
Other than the above, I'm wondering myself what's the "official"
recommendation for the C++11 threading support w/ Rcpp on Windows.

Best,

Matt

_______________________________________________
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

Reply via email to