Matthew Bromberg
2005-Nov-01 21:21 UTC
[LLVMdev] Re: Still can't compile backend or frontend on, Windows
llvmdev-request at cs.uiuc.edu wrote:>Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >or, via email, send a message with subject or body 'help' to > llvmdev-request at cs.uiuc.edu > >You can reach the person managing the list at > llvmdev-owner at cs.uiuc.edu > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of LLVMdev digest..." > > >Today's Topics: > > 1. Re: LLVMdev Digest, Vol 16, Issue 24 (Matthew Bromberg) > 2. Re: Still can't compile backend or frontend on Windows > (Henrik Bach) > 3. Re: Re: LLVMdev Digest, Vol 16, Issue 24 (Jeff Cohen) > 4. C Types -> LLVM Objects (Evan Jones) > 5. Re: C Types -> LLVM Objects (Chris Lattner) > 6. Re: C Types -> LLVM Objects (Chris Lattner) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sun, 30 Oct 2005 14:48:38 -0500 >From: Matthew Bromberg <mattcbro at earthlink.net> >Subject: [LLVMdev] Re: LLVMdev Digest, Vol 16, Issue 24 >To: llvmdev at cs.uiuc.edu >Message-ID: <43652396.7080803 at earthlink.net> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >llvmdev-request at cs.uiuc.edu wrote: > > > >>Send LLVMdev mailing list submissions to >> llvmdev at cs.uiuc.edu >> >>To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>or, via email, send a message with subject or body 'help' to >> llvmdev-request at cs.uiuc.edu >> >>You can reach the person managing the list at >> llvmdev-owner at cs.uiuc.edu >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of LLVMdev digest..." >> >> >>Today's Topics: >> >> 1. Still can't compile backend or frontend on Windows >> (Matthew Bromberg) >> 2. Re: Still can't compile backend or frontend on Windows >> (Chris Lattner) >> 3. Re: Still can't compile backend or frontend on Windows >> (Aaron Gray) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Sat, 29 Oct 2005 23:50:05 -0400 >>From: Matthew Bromberg <mattcbro at earthlink.net> >>Subject: [LLVMdev] Still can't compile backend or frontend on Windows >>To: llvmdev at cs.uiuc.edu >>Message-ID: <436442ED.9030207 at earthlink.net> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >>It's a shame this fine tool can't get better installation support for >>Windows. If it did I suspect it would get a lot more coverage. After >>5 months or so I still have no way to compile the backend tools let >>alone the C frontend on windows. I have tried both Cygwin and Mingw so >>far. MingW is preferrable since distributions of the binaries would not >>require the cygwin.dll. It would be nice if the full backend binaries >>under windows were available for download. I understand that the VC++ >>build has downloadable binaries somewhere, but it lacks the final >>support for generating executable output (correct me if I'm wrong). >> >>This time I attempted to compile the CVS version, 1.6 in the hope that >>it had better support for Windows as some of the release notes seemed to >>indicate. I followed the Mingw installation instructions on >>http://www.geocities.com/henrik_bach_llvm/ >> >>There were a bunch of Warnings during the configure phase involving >>missing utilities such as mmap and ldopen(). When I started make I died >>with the following message: >>llvm[1]: Compiling IsNAN.cpp for Debug build >>llvm[1]: Compiling PluginLoader.cpp for Debug build >>llvm[1]: Compiling SlowOperationInformer.cpp for Debug build >>In file included from >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperation >>Informer.cpp:19: >>D:/Apps/msys/mingw/bin/../lib/gcc/mingw32/3.4.4/../../../../include/unistd.h:13: >>27: unistd.h: No such file or directory >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp: >>In const ructor >>`llvm::SlowOperationInformer::SlowOperationInformer(const std::string&)': >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp:55: >>error : `SIGALRM' undeclared (first use this function) >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp:55: >>error : (Each undeclared identifier is reported only >>once for each function it appears in.) >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp:57: >>error : `alarm' undeclared (first use this function) >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp: >>In destr uctor >>`llvm::SlowOperationInformer::~SlowOperationInformer()': >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp:69: >>error : `alarm' undeclared (first use this function) >>D:/Apps/msys/src/llvmobj/../llvm/lib/Support/SlowOperationInformer.cpp:70: >>error : `SIGALRM' undeclared (first use this function) >>make[1]: *** [/src/llvmobj/lib/Support/Debug/SlowOperationInformer.o] >>Error 1 >>make[1]: Leaving directory `/src/llvmobj/lib/Support' >>make: *** [all] Error 1 >> >>(sigh) I thought operating system specific headers such as unistd.h >>were not supposed to be needed. Perhaps someone who has successfully >>compiled the backend under Windows using Mingw could point me to the >>binary executables and/or even better some link libraries. >> >> >> >>------------------------------ >> >>Message: 2 >>Date: Sun, 30 Oct 2005 00:46:23 -0500 (CDT) >>From: Chris Lattner <sabre at nondot.org> >>Subject: Re: [LLVMdev] Still can't compile backend or frontend on >> Windows >>To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >>Message-ID: <Pine.LNX.4.61.0510300044171.19210 at nondot.org> >>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >>On Sat, 29 Oct 2005, Matthew Bromberg wrote: >> >> >> >> >>>It's a shame this fine tool can't get better installation support for >>>Windows. If it did I suspect it would get a lot more coverage. After 5 >>> >>> >>> >>> >>Yup. >> >> >> >> >> >>>months or so I still have no way to compile the backend tools let alone the C >>>frontend on windows. I have tried both Cygwin and Mingw so far. MingW is >>>preferrable since distributions of the binaries would not require the >>>cygwin.dll. It would be nice if the full backend binaries under windows were >>>available for download. I understand that the VC++ build has downloadable >>>binaries somewhere, but it lacks the final support for generating executable >>>output (correct me if I'm wrong). >>> >>> >>> >>> >>I'm not familiar with the state of the windows build. >> >> >> >> >> >>>This time I attempted to compile the CVS version, 1.6 in the hope that it had >>>better support for Windows as some of the release notes seemed to indicate. >>>I followed the Mingw installation instructions on >>>http://www.geocities.com/henrik_bach_llvm/ >>> >>> >>> >>> >>1.6 has better support for building native with VC++. I know that cygwin >>works to some degree (though the release build is broken due to cygwin >>bugs?), but I'm not familiar with the state of mingw. It seems not as >>good as it could be. >> >> >> >> >> >>>There were a bunch of Warnings during the configure phase involving missing >>>utilities such as mmap and ldopen(). When I started make I died with the >>>following message: >>>llvm[1]: Compiling IsNAN.cpp for Debug build >>> >>> >>> >>> >>... >> >> >> >> >> >>>(sigh) I thought operating system specific headers such as unistd.h were not >>>supposed to be needed. Perhaps someone who has successfully compiled the >>>backend under Windows using Mingw could point me to the binary executables >>>and/or even better some link libraries. >>> >>> >>> >>> >>I don't know what the deal is, because I don't use that platform. >>However, things will not improve unless someone steps forward to >>contribute patches. If MingW is really important to you, you could dive >>in and see if you can fix some of the problems. >> >>-Chris >> >> >> >> >> >Fair enough. I probably will attempt that very thing over the next >couple of months. I'm looking for a backend to target my little >scripting language to and llvm seems like a good choice. I wish I had >more time to put into llvm. There are a couple of other compilers that >might be interesting to target as well such as the Digital Mars C++ >compiler, which also has a less restrictive license and can be obtained >freely. Are the backend tools more complete now for the MS visual C++ >compiler? Perhaps that's the way to go for Windows. The commercial >version of that compiler has gotten pretty pricey however. > >-Matt > > > >------------------------------ > >Message: 2 >Date: Sun, 30 Oct 2005 20:49:20 +0100 >From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Subject: Re: [LLVMdev] Still can't compile backend or frontend on > Windows >To: llvmdev at cs.uiuc.edu >Message-ID: <BAY19-F16F985B7A87E97DE2CE01CCF6D0 at phx.gbl> >Content-Type: text/plain; format=flowed > > > >Most of these warnings and compile errors are related to the platform >specific layer for Unix/Windows. Unfortunately, I haven't got the guts nor >time (and currently no windows/mingw platform) to go deeper into how to >implement this functionality on the Windows platform. > >However, I have kept my notes how to get rid of these warnings and compile >errors (possibly introducing erractic behavior) for the llvm tools. I'll >happily provide these notes and my assistance for whom has the time to >provide the community with binaries for Windows. > >Henrik. > > > >>I don't know what the deal is, because I don't use that platform. However, >>things will not improve unless someone steps forward to contribute patches. >> If MingW is really important to you, you could dive in and see if you can >>fix some of the problems. >> >>-Chris >> >>-- >>http://nondot.org/sabre/ >>http://llvm.org/ >> >>_______________________________________________ >>LLVM Developers mailing list >>LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > >_________________________________________________________________ >Find det, du søger på MSN Søg http://search.msn.dk > > > >------------------------------ > >Message: 3 >Date: Sun, 30 Oct 2005 12:15:21 -0800 >From: Jeff Cohen <jeffc at jolt-lang.org> >Subject: Re: [LLVMdev] Re: LLVMdev Digest, Vol 16, Issue 24 >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Message-ID: <436529D9.5030906 at jolt-lang.org> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > >No recent progress has been made on the backend tools for MS VC++. I >did just eliminate the need for any GNU tools in building LLVM with >VC++, but that only eliminates an annoyance rather than add new >functionality. > >It is the goal to generate OBJ files directly, though that is not likely >to happen in the near future. But there are other options that do work >today. The JIT does work, so you can execute programs compiled via LLVM >right now. Additionally, you can generate C code that you can then >compile with VC++, which provides an alternate route to stand-alone >executables. > > > > > > > > > >The JIT compiler is of course of great interest, but I'm also interested in static compilation and in fact this seems to me one of the intriguing features of LLVM, the fact that it can support both static and dynamic languages, with a common optimization infrastructure. (I want my cake and to eat it too.) If I wanted just static compilation I could emit C as well, or if I just wanted a JIT compiler I could emit the .NET CLR or Java bytecodes. Just as an aside, how do you support tail calls or more general functional language paradigms with your C backend? What if I don't ever want to use a call stack for my function arguments, for example? Pardon me for my woeful ignorance, but currently I presume that on Linux using an X86 CPU you can emit either object code directly or some kind of intermediate ASCII assembly code? If that is the case, then apparently the only problem is operating system specific calls in the backend of the LLVM compiler. Also I presume that the JIT compiler really is a JIT compiler and compiles genuine machine readable object code for an x86 processor (among others), that is executed in memory ; as opposed to compiling byte code that is ultimately just interpreted. I suppose therefore that I would be interested in Henrik's notes, at the very least to see how deep the rabbit hole goes, so to speak. It would be at least 2 weeks before I would be able to dig into this in earnest however. -Matt
Chris Lattner
2005-Nov-01 22:54 UTC
[LLVMdev] Re: Still can't compile backend or frontend on, Windows
On Tue, 1 Nov 2005, Matthew Bromberg wrote:>> It is the goal to generate OBJ files directly, though that is not likely to >> happen in the near future. But there are other options that do work today. >> The JIT does work, so you can execute programs compiled via LLVM right now. >> Additionally, you can generate C code that you can then compile with VC++, >> which provides an alternate route to stand-alone executables.> The JIT compiler is of course of great interest, but I'm also interested in > static compilation and in fact this seems to me one of the intriguing > features of LLVM, the fact that it can support both static and dynamic > languages, with a common optimization infrastructure. (I want my cake and to > eat it too.)Sure.> If I wanted just static compilation I could emit C as well, or > if I just wanted a JIT compiler I could emit the .NET CLR or Java bytecodes. > Just as an aside, how do you support tail calls or more general functional > language paradigms with your C backend? What if I don't ever want to use a > call stack for my function arguments, for example?Not well. It depends on the C compiler to implement these, which means it probably won't happen.> Pardon me for my woeful ignorance, but currently I presume that on Linux > using an X86 CPU you can emit either object code directly or some kind of > intermediate ASCII assembly code? If that is the case, then apparently the > only problem is operating system specific calls in the backend of the LLVM > compiler. Also I presume that the JIT compiler really is a JIT compiler and > compiles genuine machine readable object code for an x86 processor (among > others), that is executed in memory ; as opposed to compiling byte code that > is ultimately just interpreted.Actually it is much simpler than that. If you are willing to install 'gas' on your windows box (part of cygwin, for example), you can use our native backend, with tail calls etc. Being able to emit windows .o files directly only eliminates the need to have gas installed.> I suppose therefore that I would be interested in Henrik's notes, at the > very least to see how deep the rabbit hole goes, so to speak. It would > be at least 2 weeks before I would be able to dig into this in earnest > however.Great, help is certainly appreciated! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Jeff Cohen
2005-Nov-02 04:15 UTC
[LLVMdev] Re: Still can't compile backend or frontend on, Windows
Chris Lattner wrote:> Actually it is much simpler than that. If you are willing to install > 'gas' on your windows box (part of cygwin, for example), you can use > our native backend, with tail calls etc. Being able to emit windows > .o files directly only eliminates the need to have gas installed. >Well, the theory is that if you're using VC++, you do not have the GNU tool chain installed nor are you particularly interested in installing it. Also, Windows doesn't have .o files; it has .obj files :)
Henrik Bach
2005-Nov-04 10:45 UTC
[LLVMdev] Re: Still can't compile backend or frontend on, Windows
>From: Matthew Bromberg <mattcbro at earthlink.net> >Date: Tue, 01 Nov 2005 16:21:34 -0500>The JIT compiler is of course of great interest, but I'm also interested in >static compilation and in fact this seems to me one of the intriguing >features of LLVM, the fact that it can support both static and dynamic >languages, with a common optimization infrastructure. (I want my cake and >to eat it too.) If I wanted just static compilation I could emit C as well, >or if I just wanted a JIT compiler I could emit the .NET CLR or Java >bytecodes. Just as an aside, how do you support tail calls or more general >functional language paradigms with your C backend? What if I don't ever >want to use a call stack for my function arguments, for example? > >Pardon me for my woeful ignorance, but currently I presume that on Linux >using an X86 CPU you can emit either object code directly or some kind of >intermediate ASCII assembly code? If that is the case, then apparently the >only problem is operating system specific calls in the backend of the LLVM >compiler. Also I presume that the JIT compiler really is a JIT compiler >and compiles genuine machine readable object code for an x86 processor >(among others), that is executed in memory ; as opposed to compiling byte >code that is ultimately just interpreted. > >I suppose therefore that I would be interested in Henrik's notes, at the >very least to see how deep the rabbit hole goes, so to speak. It would be >at least 2 weeks before I would be able to dig into this in earnest >however.You're welcome to join me. Say when you're ready to dig... Henrik.> >-Matt > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev_________________________________________________________________ F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/