llvm dev - Nov 2005 - [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

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/

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 :)

>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/

>You're welcome to join me. Say when you're ready to dig...
I'll join in at some point, if that is okay.

I'd like to get LLVM working on MinGW running as well as Cygwin.

Aaron