similar to: [LLVMdev] Windows question: Dozens of linker warnings and errors

On Wed, May 23, 2012 at 4:38 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi again again, > > I'm trying to build my compiler frontend in C++ on Windows 7 x64 using > clang++.exe.  I want to use clang++ for my project so that I get a feel for > how mature and usable the Windows support is as I gradually get up to speed > with LLVM for Windows.  I could develop on

Thanks for the quick reply. I had a feeling that it was due to missing Windows support in clang++ and LLVM. """ This is due to clang not understanding force_inline. These functions are defined in a header included from Windows.h, so it ends up getting a definition everywhere it is included. """ How much work would it take to add support for force_inline? Are there

On Wed, May 23, 2012 at 6:12 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Thanks for the quick reply.  I had a feeling that it was due to missing > Windows support in clang++ and LLVM. > > """ > This is due to clang not understanding force_inline. These functions > are defined in a header included from Windows.h, so it ends up getting > a definition

Does Clang/Clang++ not have its own set of standard headers? Isn't this a serious issue if Clang/Clang++ is ever to outdo GCC/G++? Is there any work in progress on this? Ideally, Clang would ship as a ready-to-use installation image that included everything needed to use it as the possibly best C and C++ compiler on the market. Or, am I ahead of myself again? Cheers, Mikael -- Love Thy

On Mon, May 28, 2012 at 07:42:12PM +0200, Mikael Lyngvig wrote: > Does Clang/Clang++ not have its own set of standard headers? Isn't this a > serious issue if Clang/Clang++ is ever to outdo GCC/G++? Is there any work > in progress on this? It provides the compiler-centric headers. It doesn't replace the rest of the C runtime library. That wouldn't make much sense. Joerg

Hi again, The Visual Studio getting started guide ( http://llvm.org/docs/GettingStartedVS.html) mentions the "llvm-lit" tool, but fails to mention these things: 1. Either you need to run it from bash or a similar Unix shell, as Windows does not recognize the extensionless Python script that it is. 2. Alternatively, you can invoke it using Python like this: python bin/llvm-lit

Hi Dmitri, I am not using any kind of cache (didn't even know of ccache). I have now installed ccache. Perhaps ccache should be mentioned in the buildbot document so that every buildbot owner knows about it? It is currently running Arch Linux ARM. if there are good reasons to switch to something else, I'll be happy to do that, although I am generally very happy about Arch Linux.

On Wed, Nov 13, 2013 at 5:28 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi Dmitri, > > I am not using any kind of cache (didn't even know of ccache). I have now > installed ccache. Perhaps ccache should be mentioned in the buildbot > document so that every buildbot owner knows about it? Possibly. > It is currently running Arch Linux ARM. if there are good

Hi, [Synopsis: Mikael thinks Windows support is overlooked and that this is a strategic error. You can skip to the next mail now, if you'd like :-) Long, long, long mail follows.] Before I go on, I'd like to informally apologize for my many postings to this mailing list. I have no intentions of spamming it, but I still feel a need to grasp certain things that seem to be implied by the

Mikael Lyngvig <mikael at lyngvig.org> writes: [snip] > Yes, I am quite familiar with the CMake documentation, but why are you > asking? That's not the cmake documentation, that's the LLVM cmake documentation: a short document that tries to explain everything you need to know about cmake to build LLVM. I had the impression that you were duplicating a large chunk of the info

Thank you so much for your hard work! LLVM/Clang is in need of motivated Windows developers willing to put in the time to make the LLVM/Clang experience better on Windows :) Quick note on the reST: instead of using a construct like: **Notice:** If you only want to build 32-bit programs, you do **not** need to install MinGW64. Prefer to use the reStructuredText "admonitions" <

A quick question while I am adding a tiny section on ccache to the HowToAddABuilder document: Why do you set CCACHE_CPP2 to yes? From reading the manual, I get the impression that this is much slower than the default and that it should only be used with tricky compilers or when debugging. Is Clang such a tricky compiler? If so, I suppose Clang should be fixed, not the ccache configuration. --

Yes, sorry, the LLVM CMake documentation :-) I don't think I am duplicating a large chunk; I am continuously trying to shave off extraneous and redundant stuff off my Windows-specific document. I just managed to shave off about six lines or so because I don't like the huge introduction and explanation of what MinGW is. Now that the document covers Ninja, there's even more reason for

> > the problem is that very few LLVM developers use or know anything about > Windows. > The only way for this to change is for people who do know and care about > Windows > to step forward, work on improving Windows support, and contribute their > Windows > viewpoint to design discussions etc. > As it is now, Windows users will quite likely drop LLVM because of the

I checkout LLVM and clang from SVN, then use CMake to generate project files for Visual Studio 2010 (I started with 2008). The LLVM project compiles successfully and gives me all the tools including Clang. For a few tests, I compile C++ code with Clang which if I need to I link, I use MinGW's ld passing all the relevant object files and libraries including correctly ordering the start-up code

Hi all, Here's an updated version of my proposed "Building with MinGW on Windows" document. In summary, the document gives a step-by-step description of how to build LLVM + Clang on Windows WITHOUT having Microsoft Visual Studio installed. The high-level goal of the document is to make life pleasant for those wonderful Windows users who desire to try out LLVM and/or Clang. I

On Mon, Jun 11, 2012 at 10:52 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Hi, > > [Synopsis: Mikael thinks Windows support is overlooked and that this is a > strategic error. ...] > Synopsis of my response: It is not overlooked, it has some technical, non-technical, and manpower limitations. Allow me to briefly summarize these issues: Technical: Currently, we have

That reminds me: Do the web documents reside in a repository somewhere or should I just grab them using wget? 2012/6/14 Michael Spencer <bigcheesegs at gmail.com> > On Wed, Jun 13, 2012 at 4:02 PM, Mikael Lyngvig <mikael at lyngvig.org> > wrote: > > If nobody else is doing it, I can translate the FAQ into Sphinx as I'd > like > > to begin gradually extending

Hi, I was thinking about the potential for link-time optimizations. And the fact that you already now output LLVM bitcode to object files, archives, and perhaps even executables (that would give a .NET flavor to LLVM, I wonder if this can be made to work seamlessly on Windows [1]). Then I thought about the fact that you seem intent on supporting all native formats that you run into. I was then

Thanks for your extensive answer! I now better understand the processes involving LLVM and Clang. I figured you were like most FOSS projects: A group of dudes working more or less together towards a common objective and therefore wanted to try to tune that objective. I have contributed a Mingw64 Windows buildbot slave that fails predictably in 29 tests on each build, and I will happily offer