[LLVMdev] VC++ linking issues, revisited

[Jeff Cohen]

Jeff Cohen wrote:

> OK, there may be some light at the end of the tunnel.  I *can* force 
> an arbitrary .obj file to become part of the executable, one that is 
> not part of the executable's project.  This is sufficient to eliminate 
> the global variable hack Morten introduced for the X86 target.
>
> But this still doesn't scale very well, as I'd have to manually 
> enumerate all .objs that are transforms and insert this list into 
> every project that builds an executable that needs them.
>
> But maybe if I got *very* clever... maybe too clever:  I add a 
> post-build event to project Transforms that lists the .obj files that 
> now exist for the project and turn that into a response file that's 
> supplied to the exe link steps (if I can actually supply a response 
> file in VS...).  And do it without requiring Perl or Python or 
> whatever that may not be available.  Well, it's worth a try...

The light was an oncoming train.  Response files cannot be used within 
Visual Studio for a stupid technical reason that'd take some Microsoftie 
30 minutes at most to fix if Microsoft bothered.  Manually forcing each 
of the 73 object files in Transforms to link not only doesn't scale and 
would be a pain to maintain, but it doesn't work.  The list is too long 
for VS to handle and it gets truncated, without warning, and in the 
middle of a file name, while creating the linker response file.

So there's only two ways of dealing with this.  The first is to use 
DLLs.  To prevent code from being duplicated in multiple DLLs and the 
EXE, the bulk of the code in lib/ will have to go in DLLs.  To keep the 
number of DLLs reasonable, many projects will have to be collapsed into 
one.  There will be one DLL (and project) each for the transforms, the 
analyses, and the targets, and one catchall DLL for all common 
dependencies of the other three.

The other way is to stick a unique global variable in each transform and 
analysis, create one header file that uses the globals in all the 
transforms, and likewise for the analyses, and include that header file 
from any executable that needs its services.  There are few enough 
targets that using forced dependencies works, though this approach can 
be used here as well for consistency.

It's a safe bet the LLVM community really dislikes the second approach.  
But there's no guarantee the first approach can actually be made to 
work.  The only other option is to use makefiles to do builds and use VS 
only for debugging, something which would be really disliked by the 
Windows software development community.