[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code

[Morten Ofstad]

Chris Lattner wrote:
>>>Can you explain what goes wrong without the stub?  It's the only part that
>>>I didn't apply.
>>
>>The X86 backend doesn't get registered since there are no references to
>>symbols in X86TargetMachine the object file is never pulled in from the
>>library I create, and thus the static intializer for the RegisterTarget
>>is never called...
> 
> I'm not sure how your patch fixes it though.  The only references added by
> your change would be within the X86 library.  How does this change the
> situation?

Because I'm including the X86TargetMachine header from the application 
(Fibonacci.cpp) .. I know, I know -- but really, I tried everything to 
get the linker to cooperate. I can only generate static libraries (.lib) 
and dynamic libraries (.dll) - there is an option to the linker to force 
symbol references, but it has to be put in the final link for the 
application and then the object X which registers the target has to be 
put in the global namespace with an 'extern "C"' in front to know it's 
name. It's even worse in my opinion.

> One of the funny things about the LLVM Unix build is that we can build
> libraries in three different ways: as .a files, as .so files, and as .o
> files.  The IncludeFile hack is used for libraries compmiled to .a files,
> to make sure that the library is actually linked in.  The other two types
> of library (X86 is a .o file version) do not have this problem: they
> "library" either gets linked in as a unit or not.
> 
> I'm not sure if VC has something like this, but I strongly suspect it
> does.  The trick is getting libx86 to compile as a single unit that is
> forced to link in.

maybe it's possible to put many objects together into one with the 
visual studio compiler also, but I don't really know how to do it... 
especially not if you want to stick with the normal .sln/.vcproj build 
system...

m.