[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Nico Weber via cfe-commits]

On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> mehdi_amini added a comment.
>
> In https://reviews.llvm.org/D25932#601842, @rnk wrote:
>
> > In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote:
> >
> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if
> you don't package libLTO yourself, it is already accessible from the
> linker: it will use the one in the toolchain when needed.
> > >
> > > I don't have an immediate idea to prevent this and have the linker
> issue an error (other than removing manually libLTO from the Xcode
> installation).
> >
> >
> > So, even if clang doesn't pass -lto_library to ld64, ld64 will
> auto-discover the bundled libLTO that happens to be next to it? That could
> go badly.
>
>
> Right: until LLVM 3.8, clang was *never* passing the `-lto_library`
> option. The only way to have your own libLTO used by ld64 instead of the
> one in the Xcode toolchain was setting the environment variable
> "DYLD_LIBRARY_PATH".
> Of course was has many issues, and that's what lead us to have clang
> passing this option to ld64. Initially only when the driver was invoked
> with -flto, but recently I had issues with clients that didn't use LTO
> themselves but were having static archives they depend on that were
> containing bitcode.
>

Where those archives system libraries, or other things?

Maybe clang could sniff archives for bitcode and pass only -flto in that
case?


>
> >
> >
> >> This is the motivation behind the warning I believe: we're trying to
> prevent this situation where a user would have clang but not his own libLTO
> and may encounter an unexpected issue. Even when the user does not opt-in
> to build his own project with LTO enabled, there can be static archive
> dependencies that contain bitcode.
> >
> > I guess ld64 doesn't expose a flag like `-fno-lto` to disable this
> completely? Maybe we could pass `-lto_library /dev/null` or something?
>
> No there is no such flag, what you suggest seems to work:
>
>   $ clang -flto main.c -Wl,-lto_library,/dev/null
>   ld: could not process llvm bitcode object file, because /dev/null could
> not be loaded file '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxw0000gn/T/main-8e28a4.o'
> for architecture x86_64
>   clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> Also with an non-existing path:
>
>   $ clang -flto main.c -Wl,-lto_library,imaginary_path
>   ld: could not process llvm bitcode object file, because imaginary_path
> could not be loaded file '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxw0000gn/T/main-319618.o'
> for architecture x86_64
>   clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D25932
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161121/49300120/attachment.html>