[LLVMdev] VC++ linking issues, revisited

[Jeff Cohen]

No, VC++ has no way to combine multiple .obj files into one.  Nor is 
there any way to force the entire contents of a .lib file into an 
executable.  Believe me, I looked for a way.  Morten couldn't find one 
either.  Even Microsoft's command line tools can't do it.  Advantage:  GNU.

DLLs aren't that slow any more.  Windows is so dependent on DLLs (the 
Win32 API itself is implemented as DLLs) that a lot of effort has gone 
into optimizing them.  You wouldn't believe the number of DLLs that are 
present in a process for a program that doesn't have any DLLs of its 
own.  I even found the VC++ 6.0 runtime DLL in LLVM processes, and I 
haven't a clue how *that* got loaded (must be used by some 
system-supplied DLL).

Reid Spencer wrote:

>Jeff,
>
>There should be a way to do what we do with the Unix Makefiles and build
>re-linked object modules. That is, when we build an analysis or
>transform pass, we create two things: a .o file and a .a file. They
>contain the same code but the latter is searchable while the former is
>not.
>
>Can you not "pre-link" a bunch of .obj files together with VC++ to
>produce a new .obj file? And, when linking something like opt, will it
>not just put all .obj files that you specify into the executable? I
>think this is the best approach as it avoids some slowness in start up
>of the tool if the equivalent DLL approach was taken.
>
>Reid.
>
>On Sat, 2005-01-01 at 17:05, Jeff Cohen wrote:
>  
>
>>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.
>>
>>_______________________________________________
>>LLVM Developers mailing list
>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>>    
>>