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

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/

> Actually, GCC is designed to work with the vector's C runtime library. 
We
Err, 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/

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

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>