similar to: Recent gcc compilation

Whoops, phone rang and I forgot to cc to the list before I typed the message. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Ruben Van Boxem <vanboxem.ruben at gmail.com> > Sent: Wed, January 5, 2011 3:38:21 PM > Subject: Re: [LLVMdev] include/Config/config.h discrepancies between CMake and >autofoo builds > > > >

2011/10/6 Aaron Ballman <aaron at aaronballman.com> > On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem > <vanboxem.ruben at gmail.com> wrote: > > You're welcome! Please remember that MinGW-w64 does not mean it is > 64-bit. > > It provides both 32- and 64-bit headers/libs. The "w64" in the name was > > originally because that was the

I don't normally build using nmake.. but I just tried and it worked 100% here. Are you sure you are using the trunk? On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com>wrote: > I first sent this to the Clang dev list, but they told me to come here: > > > ---------- Forwarded message ---------- > From: Ruben Van Boxem <vanboxem.ruben at

On Thu, Oct 6, 2011 at 2:00 PM, Ruben Van Boxem <vanboxem.ruben at gmail.com> wrote: > When building LLVM/Clang, I get the following build failure: > > MinGW-w64 provides the necessary typedefs and declarations. I adjusted the > ifdef's to include a check for a the MinGW-w64-specific symbol of choice to > differentiate mingw.org vs mingw-w64. Tested on i686-w64-mingw32 and

2011/10/6 Aaron Ballman <aaron at aaronballman.com> > On Thu, Oct 6, 2011 at 2:00 PM, Ruben Van Boxem > <vanboxem.ruben at gmail.com> wrote: > > When building LLVM/Clang, I get the following build failure: > > > > MinGW-w64 provides the necessary typedefs and declarations. I adjusted > the > > ifdef's to include a check for a the MinGW-w64-specific

On Thu, Oct 6, 2011 at 2:09 PM, Ruben Van Boxem <vanboxem.ruben at gmail.com> wrote: > You're welcome! Please remember that MinGW-w64 does not mean it is 64-bit. > It provides both 32- and 64-bit headers/libs. The "w64" in the name was > originally because that was the project's principal goal, among extending > the API completeness and compatibility with MSVC.

2010/12/31 Francois Pichet <pichet2000 at gmail.com>: > I don't normally build using nmake.. but I just tried and it worked 100% > here. > Are you sure you are using the trunk? > > On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com> > wrote: >> >> I first sent this to the Clang dev list, but they told me to come here:

2013/5/30 Ruben Van Boxem <vanboxem.ruben at gmail.com> > 2013/5/25 Aaron Ballman <aaron at aaronballman.com> > >> On Fri, May 24, 2013 at 5:53 PM, Ruben Van Boxem >> <vanboxem.ruben at gmail.com> wrote: >> > Hi, >> > >> > I submitted this patch a long while ago, together with a bunch of other >> > changes (some of which got

I first sent this to the Clang dev list, but they told me to come here: ---------- Forwarded message ---------- From: Ruben Van Boxem <vanboxem.ruben at gmail.com> Date: 2010/12/31 Subject: LLVM on Windows MSVC 10 To: cfe-dev at cs.uiuc.edu Hi, I'm trying to build svn LLVM with Visual Studio 2010: cd build cmake .. -G"NMake Makefiles" nmake and several link steps fail

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> Yeah that's the two different ones I mean. Everything MS (intrinsics, >> language features etc...) is purely version-bound, so I don't even get >> why CMake insists on checking every known function prototype of for >> example "recv"

Now with patch... 2012/9/23 Ruben Van Boxem <vanboxem.ruben at gmail.com> > Hi all, > > Attached is a patch solving the build issues of a CMake build of LLVM > including compiler-rt. I tested with MinGW-w64 GCC 4.7.2 for x86 and x64. > Mostly a missing function I implemented a while back in the tests that > moved to lib, some missing typedefs and some wrong typedefs for

Ruben, 2011/1/30 Ruben Van Boxem <vanboxem.ruben at gmail.com>: > Can the tools in LLVM create a Win32 exe or dll file? Or does LLVM > still rely on Binutils and GCC for that? Is it > possible/feasable/wanted that the LLVM toolchain could do this? As you know, we need our linker! Please look into the slide in http://llvm.org/devmtg/2010-11/ "Object Files in LLVM" by

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: >>> I'm trying to build svn LLVM with Visual Studio 2010: >>> >>> cd build >>> cmake .. -G"NMake Makefiles" >>> nmake >>> >>> and several link steps fail due to a missing symbol: >>> >>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > And this is why I don't understand configure checks for windows... There's > only one/two header/library sets... The Windows SDK and MinGW. This info > should be built in IMHO... Although the panorama is not so diverse as the Unix world, there is quite a bit of variation on Windows too. Apart from the

2011/1/5 Óscar Fuentes <ofv at wanadoo.es>: > Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > >> And this is why I don't understand configure checks for windows... There's >> only one/two header/library sets... The Windows SDK and MinGW. This info >> should be built in IMHO... > > Although the panorama is not so diverse as the Unix world,

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: > Yeah that's the two different ones I mean. Everything MS (intrinsics, > language features etc...) is purely version-bound, so I don't even get > why CMake insists on checking every known function prototype of for > example "recv" and for the presence of headers it (or the project > dev!) should know are

+LLVMdev On Aug 4, 2012, at 9:45 AM, João Matos wrote: > Charles Davis did a lot of work on Win64 SEH support in LLVM, check commits r131652-r132880. > > As I haven't tested it yet, what exactly is broken? It's not finished yet. All the stuff for assembly code that uses Win64 EH is done, but not the code-gen-side stuff (cf. Win64Exception class in CodeGen). I was about to

---------- Forwarded message ---------- From: Ruben Van Boxem <vanboxem.ruben at gmail.com> Date: 2012/1/7 Subject: Re: [llvm-commits] [PATCH][Compiler-rt] Windows implementation of mmap functionality in clear_cache_test and enable_execute_stack_test To: Anton Korobeynikov <anton at korobeynikov.info> 2012/1/7 Anton Korobeynikov <anton at korobeynikov.info> > Hello Ruben

AFAIK Clang internals do assume utf8, and llvm::sys::path converts strings to utf16 on windows and calls W API functions. If somebody would like to take a look at my changes and comment on them. Here's a brief explanation of what I did: - Convert argv to utf8 using current system locale for win32 (this is done as soon as possible inside ExpandArgv). This makes the driver happy since calls to

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 >