Well Chris,
then I've to ask the guys who really have the hands into the guts of the VC++ code:
> Hi Chris,
>
> I'm reading release notes for the fifth public release of LLVM and came
> across this line:
>
> "The LLVM source code is now compatible with Microsoft Visual C++."
>
> which is almost true, if we could build the llvm tools by VC++. However, as
> I see it, we are only able to build tablegen and an x86 backend able to
> execute embedded llvm programs.
>
> What we have achieve for VC++ aren't bad at all. Just to mention the fact as
> I see it.
Ok, I'm most interested in being precise. Can you suggest something more
correct to say?
-Chris
Well, Henrik has a point. As of now, the only thing LLVM is good for
when built with VS is the JIT engine, and then only if you're willing to
write your own front end--or be satisfied computing fibonacci numbers 
That doesn't make it useless, of course, as Morten will testify, but
the market for this level of functionality can't be big. I do plan on
creating projects to build llc and lli (perhaps in time for the next
release) and that would help a lot, but without the C/C++ front end...
Yuck... what about the C runtime? I can compile a C/C++ program on Unix
and copy the bytecode file over to Windows and then (eventually)
generate assembler that NASM can turn into a binary. But what to link
against? Microsoft's C runtime library? C++ runtime is even worse, as
name mangling is completely different. Then there's __cdecl vs
__fastcall. VC++ exception handling is implemented in an utterly
different fashion than g++ also. Any words of assurance
Yuck... what about the C runtime? I can compile a C/C++ program on Unix
and copy the bytecode file over to Windows and then (eventually)
generate assembler that NASM can turn into a binary. But what to link
against? Microsoft's C runtime library? C++ runtime is even worse, as
name mangling is completely different. Then there's __cdecl vs
__fastcall. VC++ exception handling is implemented in an utterly
different fashion than g++ also. Any words of assurance
OK, I know better than to ask because I already know the answer: the
GNU frontends are going to generate code that expects to link with GNU
libraries. Other vendors' libraries need not apply. Case closed.
Actually, GCC is designed to work with the vector's C runtime library. We
do need support for fastcall and other calling convention stuff, but
that's in the pipeline anyway. The bigger issue is probably getting GCC
to grok the windows header files. I have no idea how well it does in that
department.
-Chris
I'll have to conduct an experiment to find out. But I won't say what
that experiment will be because it'll probably violate Microsoft's EULA
Well, Henrik has a point. As of now, the only thing LLVM is good for
when built with VS is the JIT engine, and then only if you're willing to
write your own front end--or be satisfied computing fibonacci numbers
Okay, I updated the release notes, please take a look all.
If it still not accurate, please give me something I can put in there that
would work better
-Chris
well, as the wine people have already had to solve this problem (as well
as the minimal gcc windows port, which compiles to native win32, not to
the cygwin unix layer), I would suggest using the headers winegcc uses.
Winegcc includes whatever magic is necessary to compile win32 programs
against wine. So somewhere in there (either wine or the min win32 gcc)
there is a set of windows API headers that are more or less source
compatible with the MS ones and gcc can grok.
I might try mingw first for the headers. The cygwin gcc now also
includes an option to act like mingw (aka not link to the cygwin posix
library) which would make me think somewhere in there are win32 headers.
http://www.mingw.org/
And of course, winelib (the tools for compiling apps to native linux
apps linked against wine, aka ELF not PE) must contain headers.
Andrew Lenharth
http://www.lenharth.org/~andrewl/