similar to: Compiling Libvirt on Windows for Hyper V support

Hi, I have attached my compressed config file. Thanks, Reza > On Aug 20, 2019, at 12:03 PM, Daniel P. Berrangé <berrange@redhat.com> wrote: > > Re-adding the mailing list CC - please don't drop it. > > On Tue, Aug 20, 2019 at 11:54:34AM -0400, reza shahriari wrote: >> Hi, >> >> I am using msys2. When I run `./configure` without any parameters

Hi, I tried that out, I got a new error about pthreads in my config.log. Could you take another look. Thanks again, Reza > On Aug 20, 2019, at 12:36 PM, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Tue, Aug 20, 2019 at 12:29:15PM -0400, reza shahriari wrote: >> Hi, >> >> I have attached my compressed config file. >> >> Thanks,

On Tue, Aug 20, 2019 at 12:29:15PM -0400, reza shahriari wrote: > Hi, > > I have attached my compressed config file. > > Thanks, > > Reza > > > > > On Aug 20, 2019, at 12:03 PM, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > Re-adding the mailing list CC - please don't drop it. > > > > On Tue, Aug 20, 2019 at

Thanks so much. I got it to go past pthreads. Now I am working on other dependencies > On Aug 20, 2019, at 1:30 PM, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Tue, Aug 20, 2019 at 01:03:40PM -0400, reza shahriari wrote: >> Hi, >> >> I tried that out, I got a new error about pthreads in my config.log. > > It finds the header file now which is

Re-adding the mailing list CC - please don't drop it. On Tue, Aug 20, 2019 at 11:54:34AM -0400, reza shahriari wrote: > Hi, > > I am using msys2. When I run `./configure` without any parameters and I still see missing pthreads impl. > > I have installed mingw64 cross compiler toolchain. Here is the output of pacman I see when searching for pthreads (they are all installed).

I am passing in: ./configure \ --without-sasl \ --without-polkit \ --without-python \ --without-libxl \ --without-qemu \ --without-lxc \ --without-openvz \ --without-libvirtd (The ones on the website: https://libvirt.org/windows.html <https://libvirt.org/windows.html>) > On Aug 20, 2019, at 3:26 AM, Erik Skultety <eskultet@redhat.com> wrote: > > On Mon, Aug

hello everyone: On this boring weekend, I tried compile R-trunk on windows 11 arm64 using clangarm64+msys2 on macbook m1 , it surprisingly easy to compiled and run. more investigation and test and code modify need to be done ,but IMO this is a good beginning !! to compile R on windows 11 arm64 just need : 1 svn checkout R-trunk and add USE_LLVM=YES in MKRules.dist or Mkrules.local 2 install

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

Hi Yaron, I know you sent me some emails before about regression testing on MSYS2 So you might have some idea about this I am getting a regression error on check-llvm. With the llvm/trunk/test/ExecutionEngine/Interpreter/intrinsics.ll FAIL: LLVM :: ExecutionEngine/Interpreter/intrinsics.ll (7635 of 14266) > ******************** TEST 'LLVM :: >

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

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.

This test results in UNSUPPORTED on my system, since config.enable_ffi = "OFF". This is the result of LLVM_ENABLE_FFI which is OFF by default. Is it turned ON in your build? 2015-07-28 17:32 GMT+03:00 Martell Malone <martellmalone at gmail.com>: > Hi Yaron, > > I know you sent me some emails before about regression testing on MSYS2 > So you might have some idea about

> > Is it turned ON in your build? > Yes it is turned on in my build here is my build script PATH=/mingw64/bin:$PATH FFI_INCLUDE_DIR="$(pkg-config --cflags libffi)" > FFI_INCLUDE_DIR=$(echo $FFI_INCLUDE_DIR | sed 's|-I||g') > > /mingw64/bin/cmake.exe \ > -G"MSYS Makefiles" \ > -DCMAKE_MAKE_PROGRAM="/usr/bin/make.exe" \ >

Oh, I forgot to mention that besides setting AR, RANLIB and the stack probing fix, you also need a very up to date binutils. 2.25 was out in december. Even with that , if you linker's default is not what you are compiling for (i.e. a multiarch toolchain), you need to set GNUTARGET also, i.e. -m32/-m64 is not enough. Some fix to autodetect non-default targets went in after christmas before the

Indeed, mingw and pthreads have C++11 atomics, so building clang (with atomics) should be possible even in cross compilation. I have no idea what is the win from *not* using winpthreads, it is one small DLL file with BSD license. For context (does not matter to mingw as host for buiilding clang but matters for clang running with mingw environment), clang TLS implementation is not same as mingw so

>>>>> Erin Hodgess >>>>> on Fri, 1 Mar 2019 12:30:35 -0700 writes: > Yay! I re-installed everything and got through "Make > distribution"! I have one more question, please: I am > running the make check-all. I have an error at reg-1d. > It stops the process. However, the mean difference (as > per the file) is

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

Sorry for bothering you I am trying to build the R grpc package on windows: https://github.com/nfultz/grpc against an MSYS2 build of grpc. when running devtools::install() I am getting the following error: C:/msys64/mingw64/include/grpc/impl/codegen/port_platform.h:47:2: error: #error "Please compile grpc with _WIN32_WINNT of at least 0x600 (aka Windows Vista)" #error \ ^ Which,

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and