search for: linkarch

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

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

...make[3]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine/RuntimeDyld' make[2]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine' make[2]: Entering directory `/mnt/EXT/00/llvm/work/src/llvm-3.0. src/lib/Linker' llvm[2]: Compiling LinkArchives.cpp for Release build llvm[2]: Compiling LinkItems.cpp for Release build llvm[2]: Compiling LinkModules.cpp for Release build llvm[2]: Compiling Linker.cpp for Release build llvm[2]: Building Release Archive Library libLLVMLinker.a make[2]: Leaving directory `/mnt/EXT/00/llvm/work/src/llvm-3.0....

...; `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine/RuntimeDyld' > make[2]: Leaving directory > `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine' > make[2]: Entering directory `/mnt/EXT/00/llvm/work/src/llvm-3.0. > src/lib/Linker' > llvm[2]: Compiling LinkArchives.cpp for Release build > llvm[2]: Compiling LinkItems.cpp for Release build > llvm[2]: Compiling LinkModules.cpp for Release build > llvm[2]: Compiling Linker.cpp for Release build > llvm[2]: Building Release Archive Library libLLVMLinker.a > make[2]: Leaving directory `/mnt/EXT/0...

...src/llvm-3.0.src/lib/ExecutionEngine/RuntimeDyld' > > make[2]: Leaving directory > > `/mnt/EXT/00/llvm/work/src/llvm-3.0.src/lib/ExecutionEngine' > > make[2]: Entering directory `/mnt/EXT/00/llvm/work/src/llvm-3.0. > > src/lib/Linker' > > llvm[2]: Compiling LinkArchives.cpp for Release build > > llvm[2]: Compiling LinkItems.cpp for Release build > > llvm[2]: Compiling LinkModules.cpp for Release build > > llvm[2]: Compiling Linker.cpp for Release build > > llvm[2]: Building Release Archive Library libLLVMLinker.a > > make[2]: Leav...

...-- John T. > > I wonder if llvm can be compiled on debian. > I use cfrontend-1.5.i686-redhat-linux-gnu.tar.gz to be compiled on > debian.But there is something wrong . > the detail is below: > make[2]: Entering directory `/home/fpeng/llvm/lib/Linker' > llvm[2]: Compiling LinkArchives.cpp for Debug build > llvm[2]: Compiling LinkItems.cpp for Debug build > llvm[2]: Compiling LinkModules.cpp for Debug build > llvm[2]: Compiling Linker.cpp for Debug build > llvm[2]: Building Debug Archive Library libLLVMLinker.a > make[2]: Leaving directory `/home/fpeng/llvm/lib...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached