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

  [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

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++

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

Change-Id: I5fd81a872339e7334889fc3b73d346586163f0dc
Commit-Queue: Brett Wilson <>
Reviewed-by: Petr Hosek <>
7 files changed
tree: deac486caf6ccdfae51ce7c55d37fa88edcb1511
  1. build/
  2. docs/
  3. examples/
  4. infra/
  5. misc/
  6. src/
  7. tools/
  8. .clang-format
  9. .editorconfig
  10. .gitignore
  11. .style.yapf
  14. OWNERS


GN is a meta-build system that generates build files for Ninja.

Related resources:

Getting a binary

You can download the latest version of GN binary for Linux, macOS and Windows.

Alternatively, you can build GN from source:

git clone
cd gn
python build/
ninja -C out
# To run tests:

On Windows, it is expected that cl.exe, link.exe, and lib.exe can be found in PATH, so you'll want to run from a Visual Studio command prompt, or similar.

On Linux and Mac, the default compiler is clang++, a recent version is expected to be found in PATH. This can be overridden by setting CC, CXX, and AR.


There is a simple example in examples/simple_build directory that is a good place to get started with the minimal configuration.

To build and run the simple example with the default gcc compiler:

cd examples/simple_build
../../out/gn gen -C out
ninja -C out

For a maximal configuration see the Chromium setup:

and the Fuchsia setup:

Reporting bugs

If you find a bug, you can see if it is known or report it in the bug database.

Sending patches

GN uses Gerrit for code review. The short version of how to patch is:

Register at

... edit code ...
ninja -C out && out/gn_unittests

Then, to upload a change for review:

git commit
git push origin HEAD:refs/for/master

The first time you do this you'll get an error from the server about a missing change-ID. Follow the directions in the error message to install the change-ID hook and run git commit --amend to apply the hook to the current commit.

When revising a change, use:

git commit --amend
git push origin HEAD:refs/for/master

which will add the new changes to the existing code review, rather than creating a new one.

We ask that all contributors sign Google's Contributor License Agreement (either individual or corporate as appropriate, select ‘any other Google project’).


You may ask questions and follow along with GN‘s development on Chromium’s gn-dev@ Google Group.