tree deac486caf6ccdfae51ce7c55d37fa88edcb1511
parent 07f614a8db14f4af27b90ecf97266466cddfc838
author Adrian Taylor <adetaylor@chromium.org> 1587959358 -0700
committer Commit Bot <commit-bot@chromium.org> 1589305024 +0000

Allow rlib linking into C++ targets.

Previously, we assumed that the only way to link Rust rlibs into C++ was
by having an intermediate Rust "static library" target, which is in
effect a complete static library containing all the dependencies of that
particular Rust code (including transitive dependencies and the standard
library).

  [rlibs] -> [Rust staticlib] -> [solink/link etc.]

But this doesn't work in cases where multiple Rust libraries may
sometimes be linked in different permutations. In Chrome we have
just that situation. In a debug build, Chrome exists as multiple
.so files, whilst in a release build, it's linked into a single
executable.

Debug build:
  [rlib A] -> [Rust staticlib A] -> [solink A]

  [rlib B] -> [Rust staticlib B] -> [solink B]

Release build:
  [rlib A] -> [Rust staticlib A] -\
                                  |
  [rlib B] -> [Rust staticlib B] -+--> [exe - violates ODR]

The ODR violations in producing the final linked product assume
there are bits of Rust stuff repeated across both staticlibs.
e.g. bits of the Rust standard library. This would also happen
if rlibs A and B both depended upon rlib C.

Furthermore, these rlibs are so deeply nested in our dependency
tree that they stand no realistic chance of determining whether
the final product is a single binary or several binaries. gn does
not encourage this kind of global knowledge anyway, and it feels wrong
for a distant rlib to make decisions based upon the final output.

Therefore, we have switched to an alternative strategy where Rust rlibs
are linked directly into the final C++ executables and shared objects,
together with the Rust standard library and other dependencies which
are normally inserted by rustc as it calls the linker.

In order to achieve this with gn, we need rlibs to be linked into C++
targets.

Instead of including them directly into the {{inputs}} for a C++
link target, they're provided as a separate

  rlibs = ...

substitution. This is because some toolchains may wish to treat them
differently (for instance, not including them inside a
-Wl,--whole-archive directive).

This should have no effect on projects using the former strategy
of linking rlibs together into a static library, because that static
library should "absorb" its dependencies rather than passing them on
to downstream C++ targets, and thus such dependencies should not be
visible to the Ninja C target writer.

An alternative would have been to place such rlibs within the existing

  libs =

subtitution; however, such entries are typically of the form "-lfoo"
and are assembled from config directives rather than OutputFile paths.

This change doesn't deliberately change any behavior relating to
Rust procedural macros. It seems questionable to have any C++ targets
ever depend directly on procedural macros; further work is required
here.

Change-Id: I5fd81a872339e7334889fc3b73d346586163f0dc
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/8260
Commit-Queue: Brett Wilson <brettw@chromium.org>
Reviewed-by: Petr Hosek <phosek@google.com>