[LLVMdev] VC++ linking issues, revisited

[Jeff Cohen]

I've gone about as far as I can in building executables with VC++.  The 
problem with the remaining ones is that they rely on the static 
constructor trick to register various modules.  This doesn't work with 
VC++ because without an explicit external reference to these modules 
they simply can't be linked in to an executable.

This isn't a new problem, of course.  Morten originally ran into this 
getting the X86 backend to link in, and solved it by introducing a 
global variable that could be used as the external reference.  The 
problem is, this doesn't scale.  There are few code generator targets, 
and fewer still that one would care to use on Windows.  But there are 
dozens of optimizations and analyses.  It's not practical or 
maintainable to give each one a global variable and then reference it 
from each affected executable.

So I can (and have, actually) build "opt", but it's just a big waste of 
bytes as it has no optimizations available to it.  And if I understand 
things correctly, it means that the JIT can't do any optimizations either.

I'm not really sure how to deal with this.  The best solution I can come 
up with is to put all of these modules into DLLs.  When a DLL is loaded, 
all of its static constructors are executed, regardless of which modules 
are externally referenced.  Nonetheless, there must be at least *one* 
external reference, or else the DLL wouldn't be loaded automatically in 
the first place.  The DLL could be manually loaded, but that would be 
introducing Windows-specific code in places you probably don't want it.  
However, one global (or dummy function) for all optimizations or all 
code generator targets or all analyses is much better than one for each 
optimization or target or analysis.

I think this will work, but it does represent a major change in how the 
VC++ build is conducted and I want to get feedback first, especially 
from Morten.