[LLVMdev] Heads Up: libLLVMCore.a and loadable modules

[John T. Criswell]

Reid Spencer wrote:

>There are some bugs against it that state the current progress. The
>problem is that it depends on how the libraries are being used. Even if
>you get past the linking problems, you will end up with re-registration
>of passes and options, etc., which causes asserts.  So, for now, there
>aren't many good solutions.
>  
>
Is it possible to link opt and analyze with VMCore.o and use libVMcore.a 
with everything else?

Also, do you know the PR# for the issue or the topics of any threads 
about it?  I get the feeling I'm asking a lot of already asked questions.

-- John T.

>Reid.
>
>On Thu, 2006-06-22 at 17:21 -0500, John Criswell wrote:
>  
>
>>Has anything been done about this issue since Reid first mentioned it?  
>>I think I'm getting bitten by it.
>>
>>-- John T.
>>
>>Reid Spencer wrote:
>>
>>    
>>
>>>The recent change in the library structure to make libLLVMCore.a instead
>>>of LLVMCore.o has caused a little fallout. The problem is LLVM tools
>>>that take a --load option to load a module dynamically may now cause
>>>those modules to fail to load at runtime. This occurs because the tool
>>>with the --load option might not be linking in all of libLLVMCore.a, but
>>>only the object modules actually needed by that tool. Consequently, a
>>>module that uses something not linked into the tool will fail to link at
>>>runtime loading.
>>>
>>>For example, Yorion experienced this problem when he wrote a shared
>>>library module that depends on DbgStopPoint which is in
>>>IntrinsicInst.cpp.  His module links fine, but when it is loaded into
>>>"opt" it fails to resolve the DbgStopPoint symbols he uses. That's
>>>because the opt program doesn't use DbgStopPoint and so those symbols
>>>are now missing because opt linked with libLLVMCore.a instead of
>>>LLVMCore.o. 
>>>
>>>Simply linking the shared library module with libLLVMCore. a doesn't
>>>help because then you get things like AsmWriterPass being registered
>>>multiple times (once from opt and once from the shared lib being
>>>loaded).
>>>
>>>The only solution Yorion and I found was to copy the IntrinsicInst.cpp
>>>code out of lib/VMCore and into his own area where it could be compiled
>>>and linked directly into his module.
>>>
>>>There may be other things that are not linked into tools like opt any
>>>more that might cause similar problems for loadable modules. 
>>>
>>>I'll file a PR on this.
>>>
>>>Reid. 
>>>  
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>LLVM Developers mailing list
>>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>  
>>>      
>>>
>>_______________________________________________
>>LLVM Developers mailing list
>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>    
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>LLVM Developers mailing list
>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>    
>>