Chris Cadwallader
2013-Jan-29 19:31 UTC
[LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)
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 linker. 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. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130129/99383b5b/attachment.html>
Eric Christopher
2013-Jan-29 20:53 UTC
[LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)
It's usually best to reply to the actual commit, I've cc'd Daniel who did that commit though. -eric On Tue, Jan 29, 2013 at 11:31 AM, Chris Cadwallader <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 > linker. > > 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. > > Thanks, > Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130129/92a9aa8c/attachment.html>
Daniel Dunbar
2013-Jan-29 20:56 UTC
[LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)
Hi Chris, 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: http://llvm.org/docs/LinkTimeOptimization.html http://llvm.org/docs/GoldPlugin.html - Daniel On Tue, Jan 29, 2013 at 11:31 AM, Chris Cadwallader <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 > linker. > > 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. > > Thanks, > Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130129/3408ec02/attachment.html>
Chris Cadwallader
2013-Jan-29 23:08 UTC
[LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)
Daniel, 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. - Chris On Jan 29, 2013, at 3:56 PM, Daniel Dunbar wrote: Hi Chris, 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: http://llvm.org/docs/LinkTimeOptimization.html http://llvm.org/docs/GoldPlugin.html - Daniel 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 linker. 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. Thanks, Chris _______________________________________________ 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/> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130129/a5b8de9d/attachment.html>
Maybe Matching Threads
- [LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)
- [LLVMdev] Setting up a cross-compiler for cortex-m3
- [LLVMdev] Setting up a cross-compiler for cortex-m3
- [LLVMdev] LLVM-3.0 fails to build on linux ppc32
- [LLVMdev] Setting up a cross-compiler for cortex-m3