similar to: New version of Rtools for Windows

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 Thu, Jan 8, 2015 at 10:48 AM, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote: > > The r.dll crash is easy - you need to be using gcc-ar for ar, and gcc-ranlib for ranlib. I also posted a patch to fix the check failure for stack probing, as lto optimizes away the stack probing code, as it should. > > yes, lto build's speed gain is very impressive. > > I

The r.dll crash is easy - you need to be using gcc-ar for ar, and gcc-ranlib for ranlib. I also posted a patch to fix the check failure for stack probing, as lto optimizes away the stack probing code, as it should. yes, lto build's speed gain is very impressive. ------------------------------ On Thu, Jan 8, 2015 2:01 PM GMT Henric Winell wrote: >On 2015-01-08 14:18, Avraham Adler

On Fri, Jan 9, 2015 at 12:19 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/01/2015 10:56 AM, Henric Winell wrote: >> On 2015-01-08 02:31, Duncan Murdoch wrote: >> >>> 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: >>>>>

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.

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

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 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

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

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 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

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

Dear All, I've tried to build xapian-core 1.4.3 on MSYS2. It fails with attached error (undefined reference to `exp10'). I think it might be missing an explicit link to 'm'. I'm not able to fix this myself as I do not know autotools sufficiently well, but I hope you might be able to help. Cheers, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel.

It seems that version of ICU_531 in <http://www.stats.ox.ac.uk/pub/Rtools/goodies/> as of June 25, 2014, was compiled using sjlj exception handling (current gcc-4.6.3, perhaps?). I say that as I am trying a 4.9.2 distribution which uses seh handling, and I get errors like: gcc -std=gnu99 -m64 -shared -s -mwindows -o R.dll R.def console.o dynload.o editor.o embeddedR.o extra.o malloc.o

I recently wrote a post on installing "Git for Windows" on a legacy XP SP3 Home box. http://nurmi-labs.blogspot.com/2016/11/git.html I added some missing files from the MSYS2 packages which were removed for the downloadable "Git for Windows" installer and a compiler and some additional libraries. For other utilities (bison, flex, info, m4, make, and csh/tcsh), and code I

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 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 it can help. I have been looking into this a bit over