Compiling with Visual Studio 2010 x64

[GoogleCodeExporter]

I try to compile with Visual Studio 2010.

I found the following problems:

1) compiler\include\tart\Common\SourceLocation.h, line 81:
  void dump() const __attribute__ ((noinline));
__attribute__ is not supported

2) compiler\lib\Gen\Reflector.cpp, line 895:
This line causes a compile error. The fix seems to be to change position of 
const to:
        innerTypes.push_back(static_cast< TypeDefn * const>(de)->typeValue());

3) runtime\lib\StdFileStream.c:
The type bool is not supported if compiled as C source. My work around is to 
add the following typedef:
#if !__BOOL_DEFINED
typedef int bool;
#endif
but this must certainly refined.

Original issue reported on code.google.com by kai.na...@gmail.com on 6 Oct 2010 at 4:56

[GoogleCodeExporter]

First, thank you for downloading and attempting to compile Tart!

It's been a few months since I attempted to compile Tart under MSVC. There are 
a number of serious problems that need to be solved before Tart can even hope 
to run. The most serious problem has to do with the fact that the cbuild 
scripts are set up to generate assembly-language files which are compiled with 
gas. My understanding is that LLVM now supports direct emission of object files 
(it didn't last time I tried), so the assembly step can be skipped. I need to 
look into this, I just haven't done so yet.

Original comment by viri...@gmail.com on 7 Oct 2010 at 12:19

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Thanks for your response.

With the attached changes, it is at least possible to create tartc.exe, 
tartln.exe and compile most of the tart library to bitcode.

I now try to integrate the new object file generation from LLVM into tartln.....

Original comment by kai.na...@gmail.com on 8 Oct 2010 at 4:39

Attachments:

• Changes.patch

[GoogleCodeExporter]

Awesome.

One thing I would ask is to make sure that we retain the ability to generate 
assembly code as an option - I've found it invaluable for debugging the 
compiler and linker to be able to read the generated assembly.

Original comment by viri...@gmail.com on 8 Oct 2010 at 5:37

[GoogleCodeExporter]

Enabling object file creation was easy - the infrastructure was already there. 
With the attached patch, an object file can be created by specifying 
-filetype=obj. This should also work on Linux, but I haven't tried it.

On Windows, the linker seems to accept the object file. Now the library is 
missing to create an executable...

Original comment by kai.na...@gmail.com on 12 Oct 2010 at 4:27

Attachments:

• tartln.patch

[GoogleCodeExporter]

OK both patches have been applied. Thanks!

Original comment by viri...@gmail.com on 13 Oct 2010 at 2:49

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for applying the patches.

Here are some more changes in order to get a working MSVC version:

1) The dsymutil is not available in MSVC. The patch conditionally excludes this 
from the CMakeLists.txt. It also suppresses one more warning. (This was 
recently added to LLVM, too.)

2) In ScopeTest.cpp a new define is required because snprintf is known as 
_snprintf to msvc.

Both changes are in the attached patched.

There is another problem in trunk\test\unit\CMakeLists.txt. The link step 
mentions a library named dl. This library does not exists under Windows. But 
the link step works perfectly without it. I am unsure if this library is really 
needed, e.g. for Linux. The solution is either to remove the library from the 
list or to create a different link step for MSVC. 

Original comment by kai.na...@gmail.com on 15 Oct 2010 at 4:06

Attachments:

• UnitTest.patch