tree dfa023f78a8df3878b3c981407c8d28a941c04a4
parent 46f94b5a7f5527b5d7ef57271d3e9447a65e22ac
author danakj <danakj@chromium.org> 1646775982 -0500
committer Commit Bot <commit-bot@chromium.org> 1646852815 +0000

Don't propagate rlibs through shared libraries for linking purposes.

If a C++ target depends on an rlib R, the rlibs are treated as libraries
for linking purposes, and all transitive dependencies of R are required
at linking time.

The above holds true within a single final linking target, such as an
executable or shared library. However currently the rlibs inside a
shared library get linked again into anything that depends on the
shared library. This results in linking issues, such as missing
symbols.

executable(A) -> dylib(B) -> rlib(C) -> rlib(D)

If A wants to use C or D, and they are public dependencies, it does
not need to link them into A. They are already linked into B and A
will be linked against B.

I believe this becomes a more visible problem when C or D depends on a
C++ static library which has non-public symbols, as then A ends up
incorrectly linking C without linking its non-Rust dependencies too.

Bug: 276
Change-Id: I8ee2c1d89190920cb5a9eee0e0b6da8a18d4a235
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/13080
Reviewed-by: Tyler Mandry <tmandry@google.com>
Reviewed-by: Brett Wilson <brettw@google.com>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Commit-Queue: Brett Wilson <brettw@chromium.org>