similar to: [LLVMdev] Regression testing on MSYS2 host with mingw-w64

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

You may be the first person to try this configuration... it would certainly be good if libffi could be made to work and these tests passing, try to see what the problem and patch it. 2015-07-28 22:04 GMT+03:00 Martell Malone <martellmalone at gmail.com>: > Is it turned ON in your build? >> > Yes it is turned on in my build > > here is my build script > >

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

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,

Hello! I'm not sure if this is the right place to post this, so apologies in advance if I'm not in the right list. I downloaded the OpenBLAS and am following Avraham Adler's great instructions. However, when I run make, things go well to a certain point, and then go bad: make [snip] touch cygopenblas_haswellp-r0.3.5.a make -j 1 -C test all make[1]: Entering directory

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

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

On Tue, Jul 28, 2015 at 10:12 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > You may be the first person to try this configuration... it would certainly > be good if libffi could be made to work and these tests passing, try to see > what the problem and patch it. I hit a similar problem on Linux but only with gcc5 as host compiler, see

Hi Ismail, They are quite possibly related as i am using gcc 5.2 also :) Did you find any upstream bug for this in gcc ? I'm looking but can't seem to find any Many Thanks Martell On Wed, Jul 29, 2015 at 7:07 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > On Tue, Jul 28, 2015 at 10:12 PM, Yaron Keren <yaron.keren at gmail.com> > wrote: > > You may be the first

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,

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 2.0e-12. I'm ok with that. How do I bypass this, please? Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodgess at gmail.com On Wed, Feb 27,

I've got a patched LLD 5.0.0 like this: diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp index 854c3e69..8bab1c11 100644 --- a/deps/lld/COFF/Driver.cpp +++ b/deps/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { if (!Args.hasArgNoClaim(OPT_INPUT)) { fixupExports(); createImportLibrary(/*AsLib=*/true); -

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

I think you want to call freeArena() before returning from lld::coff::link. On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I believe this line is the culprit: > > COFF/Driver.cpp:102: > make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); // take ownership > > Patch forthcoming. > > > On Sun, Oct

This person has had apparent success - you could follow what they did or just download their product (with appropriate caution downloading a random .exe). https://github.com/thequackdaddy/R-OpenBLAS On Thu, Feb 28, 2019 at 6:28 AM Erin Hodgess <erinm.hodgess at gmail.com> wrote: > Hello! > > I'm not sure if this is the right place to post this, so apologies > in advance if

Hi Chandler, There were five SEH releated patches posted in two threads in the last days. Two different patches in Martell e-mail starting this thread: the win64 seh (llvm) and the register names Three more related SEH patches in another thread: one for win64 seh clang, one for MinGW toolchain and another for unreachable prologue. To clarify and allow proper reviews for the different patches I

Hi, I've been hacking around something missing in the assemble for the mingw-w64 targets the tfloat variable. I did some research into the llvm sources and did see x86_fp80 which seems to be the same thing. Can we support the .tfloat variable or the alternative ? Or is it under another name? I've tried using .x86_fp80 instead but to no avail. :/ Here is how tfloat is being used in

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 good, but it still fails to find the libpthread.dll file, which is what LDFLAGS should have addressed configure:15417: checking for pthread_kill in -lpthread configure:15442: gcc -o conftest.exe

MS XP SP3 (32 bit) https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/ mingw-w64-i686-xapian-core-1.4.1-1-any.pkg.tar.xz does not contain /mingw32/lib/libxapian.la. cf: http://nurmi-labs.blogspot.com/2016/11/git.html (for setup) https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/ mingw-w64-i686-libtool-2.4.6-7-any.pkg.tar.xz (added)