Hi,
I just compiled llvm+clang with MSVC++ and tried using the -filetype=obj but clang seems to be dependent on GCC.
Aaron
Clang defaults to using GCC as a portability layer for targets that don't have a ToolChain set up in the driver. Define a ToolChain for your platform and this goes away.
-Chris
Hi Chris,
Congratulations on your ACM SIGPLAN award.
Sorry to be dumb but how or where do I define a ToolChain ?
Aaron
Take a look at clang/docs/DriverInternals.html
-Chris
Okay I have to study the code a bit, but basically I have defined a Win32HostInfo class, associated creator, and Driver::GetHostInfo() creator entry.
next a clang::driver::toolchains::Win32 class ? Should there be (“pure”) Win32Clang for native Windows and Win32GCC classes for Cygwin and MinGW to use ?
Aaron
Just the Win32 host info would be a good start.
There should be no need for a Win32Clang or Win32GCC classes. On Win32 we want to just get to the point where the integrated assembler works.
- Daniel
Hi,
I just compiled llvm+clang with MSVC++ and tried using the -filetype=obj but
clang seems to be dependent on GCC.
Aaron
Use the integrated assembler with this patch:
http://old.nabble.com/Re:-Win32-COFF-Support-p28702793.html
Just the Win32 host info would be a good start.
There should be no need for a Win32Clang or Win32GCC classes. On Win32 we
want to just get to the point where the integrated assembler works.
- Daniel
The Generic_GCC HostInfo works with -integrated-as with the COFF
patch for MC over on the llvmdev ML. No changes to clang are needed. I
have the beginnings of a WindowsClang HostInfo that defaults to
-integrated-as (no need to pass the arg) and uses MSVC link.exe for
linking. This allows "echo int main(){printf("Hello World!");} | clang
-x c -o hello.exe - && hello.exe" to work (and output what one would
expect).
It's not quite ready for review yet, mainly because I'm not sure
exactly how it all should be organized. Right now I just copy what's
done on darwin/linux as best I can.
- Michael Spencer
Could you send me a patch for this ? I have tried to do similarly but cannot
get it to work.
I am working on a COFF linker for LLVM.Aaron
http://codereview.appspot.com/1638043/show
(ignore test/CMakeLists.txt)
How are you planning on doing the linker? This is probably something
that should be done like LLVMMC. In fact they should probably share
Elf/MachO/COFF code.
Ahhhh sorry about that. I added the wrong mailing list back. Please
don't kill me :(.
- Michael Spencer
Okay, looks good, a few points.
- The Tools.cpp diff seems to be a bit odd, its done a total replacement
rather than just the changes, you may want to look into this.
I have no idea why it's like that. I made the patch with git, so I
must have messed something up in there.
- InitHeaderSearch.cpp is going to want to have a conditional '#ifdef
WIN32' round it as 'getSystemRegistryString() as this as obviously this is
not supported on non Windows platforms.
It's already ifdefed.
- We will probably want a non native WindowsToolChain for Cygwin and MinGW,
both of these require to be based on Generic GCC, and have '.o' suffixes on
object modules where are native windows wants '.obj' suffixes.
Yep, we should have Windows{Clang,MSVC,Cygwin,MinGW}. I have only
worked on the clang + windows native bit.
Its just a COFF linker, so far I have implemented COFF::ObjectModule,
COFF::Reader, COFF::Writer, COFF::Dumper.
I was hoping the Reader and Dumper could be used for a test tool.
Here's a link to the code if you are interested :-
http://www.aarongray.org/LLVM-COFF/Dumper
I am currently looking at a library ArchiveReader, and maybe a Writer too
for a library tool.
Cool, I'll take a look.
Sounds like line endings to me. Did you accidentally switch the entire
file to Windows line endings?
Sebastian
Oh duh! Thanks. One thing I hate about Visual Studio is it always
wants to mess up line endings. I should go look for a setting for
that...
- Michael Spencer