[LLVMdev] Re: Still can't compile backend or frontend on, Windows
Matthew Bromberg
mattcbro at earthlink.net
Tue Nov 1 13:21:34 PST 2005
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
More information about the llvm-dev
mailing list