[LLVMdev] VC++ linking issues, revisited

[Jeff Cohen]

Morten Ofstad wrote:

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

Ouch... sorry about that.

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

Ouch again... you're right of course.  The DLL approach won't work.

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

That's a good point.  The globals already exist (in the form of 
functions).  The header files simply need dummy code to "use" them, and 
in such a way that the VC++ optimizer doesn't think it's dead code.  A 
static constructor can do the job.  Still need to include this header in 
every file with a main() function.

>
> m.