similar to: [LLVMdev] Cross-compiling to x86_64-mingw-w64

Hi! I'm having trouble compiling llvm/clang when GCC-4.8.0 is installed. Even with llvm/clang installed (and used) and gcc-4.8 it always comes to this: /data/home/solskogen/obj/_build/llvm.final.x86_64-unknown-linux-gnu/Release/bin/llvm-tblgen -I /data/home/solskogen/mingw-w64-builder/trunk/bin/llvm/lib/IR -I /data/home/solskogen/mingw-w64-builder/trunk/bin/llvm/include -I

Yes, at some point we definitely should introduce stubs as a last resort for x86-64 relocations when the sections are too far apart, but I'd like to avoid it whenever possible. What I meant in my previous message was that I'd have RecordingMemoryManager use something other than malloc (such as the memory API used by SectionMemoryManager) to keep section near one another. -Andy From:

It's probably best to open a bug. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Thursday, January 31, 2013 12:27 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:

On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previous message was that I’d have > RecordingMemoryManager use

Hi Andrew, Looks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at

Hi Alexey, I think the most likely way to resolve this is to have the RecordingMemoryManager do something more complex to manage its allocations in such a way as to guarantee that they are all within proximity of one another. The code that is asserting is handling a relocation where code was generated to use a 32-bit relative offset in 64-bit code. If the two sections involved really are more

We have used that drive for 2 years with no issues. Amazing how much trouble people can get into when they tweak stuff... -Joe -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Christer Solskogen Sent: Tuesday, November 10, 2015 03:01 PM To: centos at centos.org Subject: Re: [CentOS] Samsung evo 840 fixes On 10.11.2015 20.18,

On 10.11.2015 20.18, Gordon Messmer wrote: > On 11/10/2015 10:14 AM, Christer Solskogen wrote: >> Queued TRIM seems to be a problem with this kind of drive (with the >> latest firmware), and a "recent" kernel (4.1.x) seems to have this >> fixed this without disabling NCQ completely. Is that patch backported >> to the "mainline" CentOS 6 or CentOS7

Hello, António. 2010/9/7 António Saragga Seabra <antseabra at gmail.com>: > I’m having a few problems building the kaleidoscope example (chapter 3) > under MinGW. To build the example I use as recommended > g++ -g -O3 toy.cpp `llvm-config --cppflags --ldflags --libs core` -o toy > sh: llvm-config: command not found You need MSYS's perl to use llvm-config on mingw. Does

I realize that it isn't much of an improvement, but AIFF supports 4GB recordings, and flac is compatible with this. Being an avid "taper" myself, I have, on many occasions recorded up to this limit, and I always back up my original recordings using flac. W64 support is more than welcome, but AIFF support gets you twice the length right away. Brian Willoughby Sound

Our DAW REAPER (www.reaper.fm) supports W64 as well. We'd be happy to share our W64 reading/writing implementations if someone wishes to integrate them into flac... -Justin Chris Cantwell wrote: > > I use Sony (previously Sonic Foundry) Sound Forge, which allows me to > save audio files in .w64 (Wave 64) format to get around the 2GB .wav > file limitation. W64 was invented by

Hello, I have dovecot 2.2.6 and pignenhole 0.4.2 running on freebsd9.1. We have a mix of unix users (/home/user) and postfixadmin users (/home/vmail/domain/user). I am using dovecot managesive with afterlogic webmail which has a managesieve plugin to set the out of office message. All works fine. I have sieve_vacation_default_period set to 1d. The problem I&#39;m trying to solve is that users

Hello, Takumi, you are absolutely right! It was a problem with Perl. Many thanks! That problem solved, tried to compile again the kaleidoscope example but unfortunatelly now I get the link errors found bellow: $g++ -g –O3 toy.cpp `llvm-config –cppflags –ldflags –libs core`-o toy c:/llvm-2.7/Release/lib/libLLVMSystem.a(Signals.o):Signals.cpp:(.text+0x4d4): undefined reference to

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

I need to build libLLVM (individual static libraries are fine at the moment) using mingw-w64 cross compilers, i686-w64-mingw32-gcc and (separately) x86_64-w64-mingw32-gcc. I'd like this to work from both Linux and Cygwin build environments. With autotools, this worked fine: ../configure --host=i686-w64-mingw32 and that's it (with mingw32-gcc-c++ installed on Fedora 23, also works fine on

A few days ago Gong Yu alerted this list to the possibility of building a 64-bit R for Windows under a recent MinGW-w64 toolchain, something we had failed to make work in 2007, 2008 and Feb 2009. We've now completed the port in the R-devel (SVN trunk) sources and are able to successfully complete 'make check-all'. An experimental installer based on this version is available at

Hi Ruben, Try adding a --build=x86_64-gnu-linux option to configure as well. I don't have that configuration locally, so I can't check to be certain, but IIRC, our configure wants all three for a cross compile like this. -Jim On Aug 21, 2011, at 7:19 AM, Ruben Van Boxem wrote: > Hi, > > I'm getting a returning build failure when building a linux->windows >

Hi, Has anyone built llvm-gcc-4.2-2.9 using mingw-w64 on Windows 7 64-bit OS? The binaries available in the download website LLVM-GCC 4.2 Front End Binaries for Mingw32/x86<http://llvm.org/releases/2.9/llvm-gcc4.2-2.9-x86-mingw32.tar.bz2> do not build applications (not surprisingly) for 64-bit Windows 7 (-m64 is disabled). I am both compiling and linking an application (to produce a

I use Sony (previously Sonic Foundry) Sound Forge, which allows me to save audio files in .w64 (Wave 64) format to get around the 2GB .wav file limitation. W64 was invented by Sonic Foundry, and is an open format as far as I know. The only programs I know about using the .w64 format at the moment are Sound Forge and Steinberg Nuendo, although there may be others out there. With increasing

2012/9/13 Kaylor, Andrew <andrew.kaylor at intel.com>: > I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32?