Jeff Cohen
2004-Nov-17 06:25 UTC
[LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
> 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.
Chris Lattner
2004-Nov-17 16:01 UTC
[LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
On Tue, 16 Nov 2004, Jeff Cohen wrote:> > 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 -- http://llvm.org/ http://nondot.org/sabre/
Chris Lattner
2004-Nov-17 16:09 UTC
[LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
> Actually, GCC is designed to work with the vector's C runtime library. WeErr, make that 'vendors' :) -Chris> 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 > >-Chris -- http://llvm.org/ http://nondot.org/sabre/
Jeff Cohen
2004-Nov-17 16:23 UTC
[LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
On Wed, 17 Nov 2004 10:01:57 -0600 (CST) Chris Lattner <sabre at nondot.org> wrote:> On Tue, 16 Nov 2004, Jeff Cohen wrote: > > > 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. > > -ChrisI'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 :)
Andrew Lenharth
2004-Nov-18 03:22 UTC
[LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
On Wed, 2004-11-17 at 10:01, Chris Lattner wrote:> On Tue, 16 Nov 2004, Jeff Cohen wrote: > > > 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.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. http://www.winehq.com/ Andrew Lenharth http://www.lenharth.org/~andrewl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041117/09365f34/attachment.sig>
Maybe Matching Threads
- [LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
- [LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
- [LLVMdev] Re: Notes on the release notes for the fifth public release of LLVM
- [LLVMdev] qsort callbacks portability issues
- [PATCH] paravirt.h