| commit | 646a62e029de4827e384c8517dc62fd3c7f85207 | [log] [tgz] |
|---|---|---|
| author | David 'Digit' Turner <digit@google.com> | Fri Nov 20 12:45:00 2020 +0100 |
| committer | Commit Bot <commit-bot@chromium.org> | Fri Nov 20 20:55:36 2020 +0000 |
| tree | 0d0378b483a8586f688a5c35ca72fe414d4e2368 | |
| parent | 4a164c8f55619e2bf79f9f62c86b8e4448c931d4 [diff] |
[rust] Fix command arguments for non-rust native dependencies.
The ninja Rust binary target writer did the following to generate
the command arguments set to 'rustc' for non-rust native library
dependencies (e.g. any native object file or shared library):
1- Collect the ordered set of each dependency's directory,
then write it as a series of `-Lnative=<dir>` arguments.
2- For any dependency whose name begins with 'lib', write it
as `-l<name>`, where <name> is the dependency's file name
without a "lib" prefix and without a file extension.
2- For non-"lib" dependencies, just use `-Clink-arg=<path>`
instead.
However, while working on the Fuchsia build system, I found that rules 1
and 2 are both problematic:
- Rule 1 means there is a possibility of linking the wrong library
in the final binary. E.g. consider a dependency list like:
dir1/libfoo.so
dir2/libbar.so
This gets translated into:
-Lnative=dir1 -Lnative=dir2 -lfoo -lbar
And if dir1/libbar.so happens to exist, it will be wrongly selected
by the linker.
- Rule 2 assumes the file extension is something like ".so", ".dylib"
or ".a" , i.e. something the linker will look for automatically,
however, in the Fuchsia build, we have to link against files named
"libc.so.debug" and "libzircon.so.debug" (where the ".debug" prefix
means these are the unstripped versions of the libraries). This
ends up translated into:
-Lnative=<dir2> -Lnative=<dir1> -lc.so -lzircon.so
And the linker will look for libc.so.so and libzircon.so.so instead
of the real files (and of course print an error message). Our
current work-around is to create link scripts with this name that
redirect to the real file, but this is ugly.
This CL simply fixes the issue by using `-Clink-arg=<path>` in all
cases. The `-Lnative=<dir>` arguments are still required to make
`#[link(...)]` directives work correctly.
Bug: 217
Change-Id: I5f7210300eea0effe3ed99b4f6aff5f07fb05518
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/10721
Commit-Queue: David Turner <digit@google.com>
Reviewed-by: Petr Hosek <phosek@google.com>
Reviewed-by: Brett Wilson <brettw@chromium.org>
GN is a meta-build system that generates build files for Ninja.
Related resources:
You can download the latest version of GN binary for Linux, macOS and Windows.
Alternatively, you can build GN from source:
git clone https://gn.googlesource.com/gn cd gn python build/gen.py ninja -C out # To run tests: out/gn_unittests
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 ./out/hello
For a maximal configuration see the Chromium setup:
and the Fuchsia setup:
If you find a bug, you can see if it is known or report it in the bug database.
GN uses Gerrit for code review. The short version of how to patch is:
Register at https://gn-review.googlesource.com. ... 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.