For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael
AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this symlink. Now, when I invoke the linker using this symlink, it properly load my custom libLTO.dylib library. According to the ld64 sources, it should have an other way to do that (using the -lto_library option), but I never managed to make it work. Le 12 nov. 2013 à 15:53, Rafael Espíndola <rafael.espindola at gmail.com> a écrit :> For dogfooding the compiler I normally use is a LTO bootstrap of clang. > > On linux that is simple to do that since clang passes the correct > plugin to the linker. > > On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should > clang set that before running the linker? Is there a better way for > clang to tell the linker which libLTO.so to use? > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Jean-Daniel
On Nov 12, 2013, at 10:09 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote:> AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. > > The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this symlink. > > Now, when I invoke the linker using this symlink, it properly load my custom libLTO.dylib library. > > According to the ld64 sources, it should have an other way to do that (using the -lto_library option), but I never managed to make it work.The -lto_library function is not functional yet. The linker lazy loads libLTO.dylib, so the lazy loading mechanism needs some enhancements to allow runtime changes to the load path. The linker does find libLTO.dylib file system relative to itself, so the symlink trick is a good way to work with that restriction. -Nick> > Le 12 nov. 2013 à 15:53, Rafael Espíndola <rafael.espindola at gmail.com> a écrit : > >> For dogfooding the compiler I normally use is a LTO bootstrap of clang. >> >> On linux that is simple to do that since clang passes the correct >> plugin to the linker. >> >> On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should >> clang set that before running the linker? Is there a better way for >> clang to tell the linker which libLTO.so to use? >> >> Cheers, >> Rafael >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Jean-Daniel > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
We do it by setting DYLD_LIBRARY_PATH. That overrides the normal @executable_path lookup. On Nov 12, 2013, at 10:09 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote:> AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. > > The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this symlink. > > Now, when I invoke the linker using this symlink, it properly load my custom libLTO.dylib library. > > According to the ld64 sources, it should have an other way to do that (using the -lto_library option), but I never managed to make it work. > > Le 12 nov. 2013 à 15:53, Rafael Espíndola <rafael.espindola at gmail.com> a écrit : > >> For dogfooding the compiler I normally use is a LTO bootstrap of clang. >> >> On linux that is simple to do that since clang passes the correct >> plugin to the linker. >> >> On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should >> clang set that before running the linker? Is there a better way for >> clang to tell the linker which libLTO.so to use? >> >> Cheers, >> Rafael >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Jean-Daniel > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev