[LLVMdev] VC++ linking issues, revisited

[Morten Ofstad]

Hello,

I've been away working on other things so I have not been able to 
respond to mails on this mailing list for a while. But today I got back 
and I got the latest version of LLVM from CVS and built it successfully 
(after I deleted my old config.h which was included instead of the one 
in the new location)...

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.

However I can no longer link it with our main project since the 
X86TargetMachine symbol is gone, and the intermediate object files are 
not available to the other project. I can't easily do the same as the 
fibonacci example does, so I have to put it back to the way it was.

> 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.

I only have the problem with the X86TargetMachine because in the case of 
the optimization passes I explicitly call the createXXXPass functions. 
'opt' creates passes by name instead and that's why it gets into trouble.

> 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.

I looked at this, but the problem is that DLLs need explicit __declspec( 
dllimport) and __declspec(dllexport) on all symbols that are to be 
exported and imported. I think adding the declarators to all the symbols 
that are exported/imported is a lot of work and also pollutes the source 
for the Unix versions.

> 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.

I think this solution is quite OK considering almost all the modules 
already have such global symbols, namely the createXXXPass functions.

m.