Jeff Cohen wrote:> Morten Ofstad wrote:
>> Jeff Cohen wrote:
>>
>>> The recent issues concern the head revision, post 1.9. As no one
has
>>> ever submitted patches to fix 2005 problems with the 1.9 release,
it is
>>> safe to say they still exist.
>>>
>>
>> For the 1.5 release I submitted patches that made everything compile
correctly with VS2005, I think there are some mails
>> in the archives about the issues I ran into. I also submitted patches
to make everything compile on x64 windows, but
>> since there was no x64 backend at that point it could only produce
32-bit code. I think there are only small problems
>> with new code that need to be fixed, but since my company doesn't
use LLVM at the moment it's hard for me to justify
>> spending time on it...
>>
>> m.
>>
>>
> Even just mailing me a build log showing the problems would be a big help.
I just spent an hour to get the latest CVS version and compile it with VS2005 --
apart from a small problem with an
outdated bison on my system I ran into a few problems. First of all there seems
to be some dependency problem with
Intrinsics.gen so the first time you build it has not been generated before the
first time it's included. I suspect this
is the same with VS2003 if you make a completely clean checkout from CVS and try
to build. Second, the VS2005 compiler
gives an error when compiling TargetInstrInfo.h:getPointerRegClass() (line 386)
because the function doesn't return a
value (it abort()s so it's not really a problem), just add this line at the
end of the function:
return NULL; // Must return a value in order to compile with VS 2005
There's a ton of warnings, a few of which seem to be 'real' but most
are just noise - I don't have time to go through
them, but I can mail you the build logs if you're really interested.
Last there is an annoyance in that the FileParser.y custom build rule
doesn't find the output, so it is run every time
you build. This wouldn't be so bad if it was only this file, but it in turn
causes Intrinsics.gen to be generated every
time and this causes a lot of other files to be rebuilt. I hacked the
dobison.cmd script so it never detects bison and
always copies the .cvs files to get around the bison version problem, so I
thought I had found the problem when I saw
that the .output file from bison was entered as one of the outputs of the build
step. But removing this from the outputs
didn't help, it's still executing the custom build rule every time. The
strange thing is it works fine for FileLexer.l.
Anyway, it was not too much trouble to get it going - I can check that it works
again before the 2.0 release of LLVM if
you remind me to...
m.