similar to: [LLVMdev] problem with llvm-config when building 3.1 for Linux-to-Windows cross development

Does svn r156448 help at all? It is supposed to install a separate llvm-config-host when cross-compiling. On Jun 7, 2012, at 1:30 AM, Eric Smith <eric at brouhaha.com> wrote: > Recently I packaged LLVM 3.0 for cross development use on Fedora Linux > targeting Windows using MinGW, and submitted it for a Fedora package > review. Getting that to build went pretty smoothly. >

Kenneth Boyd <zaimoni at zaimoni.com> writes: > I'm indulging in this exercise to enable testing a native MingW32 build > of LLVM in Windows. If LLVM's DejaGNU usage is the same as GCC's, I'll google or ask on the MinGW mailing list how MinGW testers run the GCC testsuite, before trying to fix something that maybe is not broken. > There are more portability

On Mon, Jun 18, 2012 at 12:25 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi all, > >     3. The document now covers 32-bit and 64-bit builds with MinGW tools (if > anybody know of an alternate BINARY distribution of MinGW64 than Drangon's > release, please let me know so I can include it in the document). As was once explained to me by Ruben Van Boxem, what you

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > >> I'm indulging in this exercise to enable testing a native MingW32 build >> of LLVM in Windows. >> > > If LLVM's DejaGNU usage is the same as GCC's, I'll google or ask on the > MinGW mailing list how MinGW testers run the GCC testsuite, before > trying to

Hi, I recently switched over to using cmake to build my clang/LLVM based ELLCC cross development project (http://ellcc.org). I also recently updated to LLVM svn version 258915 from 258477. I use ELLCC to cross compile all the tools for various Linux targets and for Windows. Yesterday, after updating the LLVM sources, I got the following error when cross building for MinGW: [ 3%] Built

I started working on some R bindings for mongo-c-driver [1]. The C library compiles fine on Ubuntu Trusty (gcc 4.8.2) and osx (clang), however on my windows machine (gcc 4.6.3 from Rtools 3.1) it fails with: 'INIT_ONCE_STATIC_INIT' undeclared. Google suggests that this might be a problem in older versions of mingw-w64. So I grabbed a copy of mingw-w64 version 4.8.3 and indeed, here the

I posted this to the comp.lang.tcl newsgroup, but it might relate to a possible bug in the Mingw32 cross-build environment under CentOS 6 (or EPEL). Forwarded Message: From: Robert Heller <heller at deepsoft.com> Subject: Cross Building Tcl using Mingw32-gcc (4.9.2) Newsgroups: comp.lang.tcl Message-ID: <Nc-dnd1wRNTsy6PInZ2dnUU7-b-dnZ2d at giganews.com> Date: Mon, 27 Apr 2015

On Fri, 6 Nov 2020, Cág via llvm-dev wrote: > The process, in my opinion, should go like this: > 1. Get the sources (llvm, lld, compiler-rt, libunwind, libcxx...). > 2. Build an LLVM cross-compiler toolchain using native distribution's > compiler (i.e. build an x86_64 clang executable that targets aarch64). > 3. Cross-compile libc and other libraries/dependencies to run the

"Friedman, Eli" <efriedma at codeaurora.org> wrote: > On 11/30/2018 8:31 AM, Stefan Kanthak via llvm-dev wrote: >> Hi @ll, >> >> compiler-rt implements (for example) the MSVC (really Windows) >> specific routines compiler-rt/lib/builtins/i386/chkstk.S and >> compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() >> See

Hi I tried to cross compile R under Linux but get an error. i586-mingw32-gcc -isystem /home/schouwl/unpack/mingw/include -O2 -Wall -pedantic -I../include -I. -DHAVE_CONFIG_H -DR_DLL_BUILD -c dynload.c -o dynload.o dynload.c: In function `R_loadLibrary': dynload.c:94: warning: implicit declaration of function `_controlfp' dynload.c:94: error: `_MCW_IC' undeclared (first use in this

Richard Smith wrote: > I am working on a port of LLVM targeting a proprietary VM. Thus far > development has been under Linux and Cygwin. Cygwin licensing would appear > to require that LLVM built under Cygwin would have to be released under the > GPL, so alternatives are being investigated. > > Using MS Visual Studio and following the instructions at >

Hi Anton, >From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs especially as we're not targeting the MSVC abi, it's just the windows abi? -eric On Wed, Mar 27, 2013 at 1:32 PM, Anton Korobeynikov <asl at math.spbu.ru>wrote: > Hi Timur, > > I myself find the name "Win32" pretty confusing and easy to misuse > (especially

It's worth noting that gcc chose *not* to support any ABI changing flags. I'm in favor of avoiding flags here. We can simply document that clang 3.3 and earlier works with gcc 4.6 and earlier, and clang 3.4+ works with gcc 4.7+. On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > Mingw switched abis with the release of gcc 4.7 >

Greg Pettyjohn <gregp at ccs.neu.edu> writes: > I'm using a little shell script: [snip] > confopts="--prefix=$PREFIX" > confopts="$confopts --disable-threads" > confopts="$confopts --disable-nls" > confopts="$confopts --disable-shared" > confopts="$confopts --enable-languages=c,c++" >

I encountered several strange issues when linking to R.dll on Windows and I wonder if anyone of the Windows savvy-folks here had seen some of the issues before and have some explanation. My Rserve links to R dynamic library. That works perfectly on unix boxes and worked fairly well with older MinGW and older R (<=1.7.1). What I do in fact is that I specify -L$(R_HOME)/bin -lR when linking.

I'm using a little shell script: BUILD_ROOT=/home/llvm-1.7/cfrontend PREFIX="$BUILD_ROOT/install" LOCAL_BUILD_DIR="$BUILD_ROOT/build" SOURCE_DIR="$BUILD_ROOT/src" echo $__me: Building $TARGET echo $__me: BUILD_ROOT == $BUILD_ROOT echo $__me: SOURCE_DIR == $SOURCE_DIR echo $__me: LOCAL_BUILD_DIR == $LOCAL_BUILD_DIR echo $__me: PREFIX == $PREFIX

Thanks. I'll try some of this. Further comments in-line: On Sun, 23 Apr 2006, Oscar Fuentes wrote: > Greg Pettyjohn <gregp at ccs.neu.edu> writes: > > > I'm using a little shell script: > [snip] > > confopts="--prefix=$PREFIX" > > confopts="$confopts --disable-threads" > > confopts="$confopts --disable-nls" >

Cross-compiling from Ubuntu 8.04 x86_64 to mingw with the cmake build system fails with this error while linking some tools: ../../lib/libLLVMSystem.a(DynamicLibrary.cpp.obj):DynamicLibrary.cpp:(.text+0x367): undefined reference to `___eprintf' ___eprintf is mentioned in lib/System/Win32/DynamicLibrary.inc. This symbol is referenced by libLLVMSystem.a when LLVM is natively built on

Hi all, I have just commited a couple of small fixes [0] to allow libogg to be compiled using the MinGW cross compile tools on Linux to generate Win32 binaries (include a DLL) and run the tests under Wine (the windows emulator). On Ubuntu (or Debian) do you will need to install the following: apt-get mingw32 mingw32-binutils mingw32-runtime wine To configure and build do: ./configure

Hi there! I've downloaded the MinGW shell, installed it as descripted in intall.txt, and also the gcc-core-3.4.2-20040916-1 and installed it. Then I've tried running ./configure, but this is what the process returns: Giacomo@NOME-0C20A03AFA /C/tinc-1.0.5 $ ./configure checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for