[PATCH] D23531: [Darwin] Stop linking libclang_rt.eprintf.a

[Daniel Dunbar via cfe-commits]

The original motivation for organizing things this way was to try and
always be in the situation where, when linking against the latest
deployment target, we should never need the extra library (because the
content will be present in libSystem). This is useful in helping to ensure
we don't unnecessarily embed copies of system provided functions.

I know it is quite cumbersome to maintain that policy, but have we
explicitly given it up? Nick, what is your opinion here?

 - Daniel

On Mon, Aug 15, 2016 at 3:51 PM, Chris Bieneman <beanz at apple.com> wrote:

> beanz created this revision.
> beanz added reviewers: ddunbar, bob.wilson.
> beanz added a subscriber: cfe-commits.
>
> The eprintf library was added before the general OS X builtins library
> existed as a place to store one builtin function. Since we have for several
> years had an actual mandated builtin library for OS X > 10.5, we should
> just merge eprintf into the main library.
>
> This change will resolve PR28855.
>
> As a follow up I'll also patch compiler-rt to not generate the eprintf
> library anymore.
>
> https://reviews.llvm.org/D23531
>
> Files:
>   lib/Driver/ToolChains.cpp
>
> Index: lib/Driver/ToolChains.cpp
> ===================================================================
> --- lib/Driver/ToolChains.cpp
> +++ lib/Driver/ToolChains.cpp
> @@ -483,8 +483,6 @@
>      if (isMacosxVersionLT(10, 5)) {
>        AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.10.4.a");
>      } else {
> -      if (getTriple().getArch() == llvm::Triple::x86)
> -        AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.eprintf.a");
>        AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.osx.a");
>      }
>    }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160816/6b6b8743/attachment.html>