[LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)
ccadwallader at arxan.com
Tue Jan 29 15:08:17 PST 2013
Thanks for the reply. We use LinkInFile() to pull in input bitcode files that can include archives and link them into a single bitcode module which we operate on. I will look into how llvm-link achieves this. Part of this process includes subclassing llvm::Linker so that we can modify LinkModules to map individual symbols to their source bitcode module.
We do need to be able to pull objects (bitcode only) out of archives so I will look into the gold plugin as well.
On Jan 29, 2013, at 3:56 PM, Daniel Dunbar wrote:
What functions were you using, and what features of them were you using? If you just need to link individual bit codes together, you can do it in exactly the same way that llvm-link does (using Linker::LinkModules).
If you really need features like being able to pull objects out of archives, then you should use an LTO enabled linker (either the system linker on OS X, or gold + the gold plugin on Linux). See also:
On Tue, Jan 29, 2013 at 11:31 AM, Chris Cadwallader <ccadwallader at arxan.com<mailto:ccadwallader at arxan.com>> wrote:
r172749 removed Linker/LinkArchives.cpp and Linker/LinkItems.cpp citing:
This code is dead, and the "right" way to get this support is to use the
platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM
Could someone please expand on what the "right way" is and these LTO mechanisms or where I can find further information? We used several functions in LinkItems.cpp to create a single bitcode module prior to processing.
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev