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

[John Criswell]

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
>