[PATCH] D53796: [libcxx] Use AS_NEEDED command for linker script inputs

[Roland McGrath via Phabricator]

mcgrathr added a comment.

In https://reviews.llvm.org/D53796#1288166, @MaskRay wrote:

> Is this patch still needed now that Fuchsia uses:
>
>   CmdArgs.push_back("--push-state");
>   CmdArgs.push_back("--as-needed");
>   if (OnlyLibstdcxxStatic)
>     CmdArgs.push_back("-Bstatic");
>   ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
>   if (OnlyLibstdcxxStatic)
>     CmdArgs.push_back("-Bdynamic");
>   CmdArgs.push_back("-lm");
>   CmdArgs.push_back("--pop-state");


We chose to address this in the driver for Fuchsia specifically so as not to be blocked on the resolution of the change here.
To be pedantic, I advocate both changes but for slightly different reasons:

1. Using `--as-needed -lc++` in the compiler driver is an assertion about the API contract between the compiler and the `-lc++` implementation.  It asserts that the sole purpose of `-lc++` is to satisfy link-time symbol references generated by the compiler.  If there are no symbols to be resolved, the compiler is not obliged to include `-lc++` in the link.  This assertion is wrong if we decide instead to say that the API contract between the compiler and the `-lc++` implementation is that if the user enabled the standard library then `-lc++` should be included in the link.  That makes it possible e.g. to have the `-lc++` implementation decide to include a shared library initializer that *must* run in a program that "enabled the standard library" even if there are no link-time symbol references.  It's my humble opinion in general, and my authoritative assertion for the Fuchsia-specific API contract between compiler and `-lc++` implementation, that an API contract compatible with `--as-needed` link-time behavior is the preferable API contract there.  I think other compiler configurations should make that choice of API contract and use optimal linker switches accordingly, but that is up to them.

2. Having `libc++.so` be a linker script provided by the libc++ implementation means that the linker script is responsible for meeting the API contract with the compiler and translating that into the ABI contract with the libc++.so.N shared library implementation (and future implementations that should drop in and be ABI-compatible).  Whether the compiler decides to eagerly use `-lc++` or not, libc++ can make the choice for its own ABI that there will never be a future ABI-compatible implementation where there is any need to load `libc++.so.N` at runtime (to run its initializer or anything else) *except* as needed to satisfy link-time symbol references.  I think that's a sensible and desirable choice for libc++ to make independent of whether the API contract with the compiler constrains it to do so or not.  In actual practice, there are many compilers and compiler versions and configurations around that might be used to link against `-lc++` as provided by tomorrow's libc++, so IMHO it best serves all those users to be optimal here even if it's redundant with some compiler configurations.


Repository:
  rCXX libc++

https://reviews.llvm.org/D53796