llvm dev - Oct 2004 - [LLVMdev] Linker problems with Visual Studio

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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20041014/f21975d2/attachment.txt>

On Thu, 14 Oct 2004, Morten Ofstad wrote:
> 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

-- 
http://llvm.org/
http://nondot.org/sabre/

On Oct 14, 2004, at 6:17 PM, Chris Lattner wrote:
>> 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..

-----------------
Paolo Invernizzi