I finally managed to compile a working fibonacci example (using the interpreter, I'm still working on porting the x86 backend). The final problem was that I couldn't find a way to force the linker to include
the Dominators.obj file since there were no references to it. There is an option to the linker to stop it from stripping unreferenced code, but it still doesn't pull the object file in from the library unless there are some references.
In the end I opted for the ugly IncludeFile() trick which is used elsewhere in the code, I include a patch with this mail. If someone has any better suggestions for how to fix this, I am all ears...
The other areas which have to be resolved is the struct/class debacle and also the hash_map usage (I am using the Visual Studio STL library) -- my fix for the hash_map thing is too ugly to go in, so I won't even bother to submit a patch. Unfortunately I have to link LLVM with our own app which is using the MS STL, so resorting to using a STL library more similar to GCC is probably not an option.
There are some other minor things I plan to submit patches for later today, when I have cleaned up. If anyone else is interested in obtaining my VS project files, please write me an email...
m.
diff.txt (1.32 KB)
I finally managed to compile a working fibonacci example (using the
interpreter, I'm still working on porting the x86 backend). The final
problem was that I couldn't find a way to force the linker to include
the Dominators.obj file since there were no references to it. There is
an option to the linker to stop it from stripping unreferenced code, but
it still doesn't pull the object file in from the library unless there
are some references.
In the end I opted for the ugly IncludeFile() trick which is used
elsewhere in the code, I include a patch with this mail. If someone has
any better suggestions for how to fix this, I am all ears...
Yes, I think this is the only way to do this unfortunately. I too would
be interested in any ideas. 
The patch is applied, thanks!
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041011/019290.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041011/019291.html
The other areas which have to be resolved is the struct/class debacle
and also the hash_map usage (I am using the Visual Studio STL library)
-- my fix for the hash_map thing is too ugly to go in, so I won't even
bother to submit a patch. Unfortunately I have to link LLVM with our own
app which is using the MS STL, so resorting to using a STL library more
similar to GCC is probably not an option.
I'm not really sure what the right way to do this is, but if you can come
up with a non-invasive patch (i.e., just to the Support/hash_* headers), I
think that would be fine. It would be very very nice to be able to use
the standard VC STL.
There are some other minor things I plan to submit patches for later
today, when I have cleaned up. If anyone else is interested in obtaining
my VS project files, please write me an email...
Cool. I'm not sure what the right approach is for the build system, as we
really don't want to maintain two completely separate build systems, one
of which that we don't test. Any ideas are welcome!
Thanks for all of the great patches!
-Chris
The other areas which have to be resolved is the struct/class debacle
and also the hash_map usage (I am using the Visual Studio STL library)
-- my fix for the hash_map thing is too ugly to go in, so I won't even
bother to submit a patch. Unfortunately I have to link LLVM with our own
app which is using the MS STL, so resorting to using a STL library more
similar to GCC is probably not an option.
I'm not really sure what the right way to do this is, but if you can come
up with a non-invasive patch (i.e., just to the Support/hash_* headers), I
think that would be fine. It would be very very nice to be able to use
the standard VC STL.
It would be really great indeed. I've had problems also with hash_set...
But really we cannot pretend a lot, it's a natural consequence of using stuff that is not in the standard...
Cool. I'm not sure what the right approach is for the build system, as we
really don't want to maintain two completely separate build systems, one
of which that we don't test. Any ideas are welcome!
I think that providing hand-made VS files for releases it's the only option if the developer wants to stick with a plain VS solution.
But I'm wondering how visual studio can handle the generation of .h files from .h.in, so you have to provide them too I guess
Mine scons solution it's an hybrid, It has the full power of standard *nix configure/make and can generate uptodate VS projects, but that projects must be used along with scons. It drive the build process when you press the build button.
Again I'm not pushing for a scons solution, I'm simply using it as It keeps my build always uptodate without having to be paranoid in checking the cvs co logs, and it's able to handle all the dependencies correctly: td files, flex and bison, .in files and so on.
I've a flue and I'm writing with 39 degree fever, so excuse me if I'm particulary dumb 
I'll be out of the LLVM game for a couple of days at least..