Getting ld64 to use a non system libLTO.dylib

[Nick Kledzik]

On Apr 29, 2014, at 4:39 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

> Since ld64 uses a library instead of a plugin, the clang driver cannot
> simply pass a -plugin option to point it to the correct one. This
> leads to bugs like llvm.org/pr18641 where ld64 loads the system
> libLTO.dylib and that is then surprised to find IR constructs that
> didn't exist when it was built.
> 
> Once understood, the bug is easy to work around, just set DYLD_LIBRARY_PATH.
> 
> Should clang patch DYLD_LIBRARY_PATH when running ld64? Is there a
> better way for it to inform ld64 of the correct library to use?

I do have a bug to add a command line option to the linker to specify the path to the libLTO.dylib that the linker should use.  

If someone is building TOT clang, where is libLTO.dylib built and how would the
clang driver know to use it?    How does the just built clang find ld64 (it is buried in Xcode these days).   

Assuming the clang build system figures that all out, yes setting DYLD_LIBRARY_PATH before invoking ld64 could work.  Or the clang build system could set up a symlink to the linker relative to the built libLTO.dylb, such that when the linker tries to find libLTO.dylib relative to itself, it finds the just build libLTO.dylib.

-Nick