similar to: Build for OSX under windows

Thanks, But this didn't work. It installs msys2 along with lots of other stuff, and gdb would not start as before (missing DLL's). Then I tried to run the command you suggested again, and there was a warning from the package manager about a cycle detected, but now gdb starts with the following messages... Traceback (most recent call last): File "<string>", ine 3, in

On 1/18/23 19:41, Dominick Samperi wrote: > Thanks for the detailed feedback Tomas, > > I ran the command 'pacman -Syuu' again, just to be sure, and this time > it says "there is nothing to do." > > It appears that gdb is working. I was spooked by the diagnostics that > you say is a known (not serious) issue. > > My mistake was not setting a

On 1/18/23 17:39, Dominick Samperi wrote: > Thanks, > > But this didn't work. It installs msys2 along with lots of other > stuff, and gdb would not start as before (missing DLL's). > > Then I tried to run the command you suggested again, and there was a > warning from the package manager about a cycle detected, but now gdb > starts with the following messages...

Thanks for the detailed feedback Tomas, I ran the command 'pacman -Syuu' again, just to be sure, and this time it says "there is nothing to do." It appears that gdb is working. I was spooked by the diagnostics that you say is a known (not serious) issue. My mistake was not setting a breakpoint on main, so I confused problems with gdb with problems with the program I'm

I have just uploaded to CRAN a new version 3.2.0.1948 of Rtools for Windows. This will become visible there in a few hours, and be copied to mirrors thereafter. People who want to build packages that include compiled code can use this to supply the compilers, etc., that are necessary for the build. It also includes some extra materials for people who want to build R itself. This version

On second thought, there is a lot of metapramming code in Rcpp that runs before main, so I was wrong to say nothing can happen before main() is called. Strategically placed print statements may be the best strategy. On Wed, Jan 18, 2023 at 8:17 PM Dominick Samperi <djsamperi at gmail.com> wrote: > Since these ?stray threads? were appearing before I installed gdb into > Rtools42, this

If the subject of xapian-core apitests on MSYS/MINGW and MSYS2/MINGW is taken up it might be noted that the compiler version could be recorded, probably gcc 5.3.0 or newer, that closed pipes might be an issue, and also allocating for the location of xapian-tcpsrv. Not from my own tests but another man informed there was some problems with [MSYS2] python bindings. I am not knowledgeable of the

On 07/01/2015 5:20 PM, Jeroen Ooms wrote: > On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> >> This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building

Yep - simpleITK is available at github.com/SimpleITK/SimpleITK. There's also github.com/SimpleITK/SimpleITKRInstaller - a devtools based installer for mac and linux. CMake has a range of build environments. I experimented with MSYS2 and mingw makefiles, but had trouble with incompatibilities in the path required by CMake and those options - from memory the sh in RTools/bin caused problems.

My apologies for cross-posting. I found this site, after I had posted on stack-overflow. I need to compile several static libraries (C & Fortran) which will later be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 directory which I understand creates 32 bit binaries. Yet, there are other 64 bit directories as well. I have three related questions: 1. Can

Hi, I am trying to compile Libvirt from the source code on windows using msys2 but keep hitting issues while running `./configure`. …. > checking whether C compiler handles -Wno-suggest-attribute=pure… yes > checking whether C compiler handles -Wno-suggest-attribute=const... yes > checking for how to force completely read-only GOT table… > checking for how to avoid indirect lib

On 30/05/2015 13:14, Duncan Murdoch wrote: > On 29/05/2015 4:16 PM, Sue McDonald wrote: >> My apologies for cross-posting. I found this site, after I had posted on >> stack-overflow. >> >> I need to compile several static libraries (C & Fortran) which will later >> be linked with an R package. Rtools33 directory includes /i686-w64-mingw32 >> directory

Dear all, In the official document <https://llvm.org/docs/CompileCudaWithLLVM.html>, it is mentioned that CUDA compilation is supported on Windows as of 2017-01-05. I used msys2 to install clang 5.0.1. Then I installed cuda 8.0. However, I basically could not compile any code of cuda by the prescribed setting. I wounder if anyone can successfully compile cuda code by the clang on Windows.

Hi, Apologies for breaking the threading on this, I've only just signed up to the list and the last email was from September 2015. I've started to look into building R for Windows using MSYS2 as both the build environment and tools + libraries provider (where possible). I've managed to get the testsuite to pass on a recent MSYS2 MinGW-w64 x86-64 GCC: gcc.exe (Rev1, Built by MSYS2

Very timely, as this is how I got into the problem I posted about earlier; maybe some of the problems I ran into will mean more to the you and the experts on this thread, Dr. Murdoch.For reference, I run Windows 7 64bit, and I am trying to build a 64 bit version of R-3.1.2. As we discussed offline, Dr. Murdoch, I've been trying to build R using more recent tools than GCC4.6.3 prerelease.

On 1/18/23 04:33, Dominick Samperi wrote: > Hello, > > I tried installing gdb into Rtools42 following the instructions here > https://cran.r-project.org/bin/windows/base/howto-R-4.2.html > > I ran 'pacman -Sy gdb', and the installation seemed to complete without > problems. > > But gdb could not be started because incorrect DLL versions were installed, > in

I believe that repo just follows the directions on my blog. Without seeing Dr. Hodges?s code, my initial concern is the many references to Cygwin. My method specifically does not use Cygwin but MSYS2 and Mingw64/Rtools35. That will likely change to solely Rtools40 once R3.6 is released due to the Msys system being built in to it. There may be some library conflicts between Cygwin and

On Tue, 10 Oct 2006, Roman Levenstein wrote: >>> such a call instruction? >> >> Why not just make the asm string be "call __fsub64"? > > Well, of course it would be the best solution. But the interesting part > is that I need to generate the machine code directly because for > different reasons use of a system assembler is not an option. As a ok. >

Hello, I am working on the SimpleITK package for R. This is an enormous package that is largely automatically generated via a set of swig/json/lua magic, and is working well under linux and osx. However we're having a lot of trouble with the Windows side. In fact, we are struggling to get the base libraries to build using the RTools 3.4 toolchain, even before the worrying about the R-specific

Hi, >> My target supports only f64 at the moment. >> Question: How can I tell LLVM that float is the same as double on my >> target? May be by assigning the same register class to both MVT::f32 ?> and MVT::f64? >Just don't assign a register class for the f32 type. This is what the >X86 backend does when it is in "floating point stack mode". This will