A static_library or source_set target may require custom linker flags. Since neither static_library or source_set produce linker output, the linker flags need to be pushed to any dependent target that does produce linker output, such as an executable, shared_library, or loadable_module.

Although “libs” in GN propagate automatically in this manner, “ldflags” do not.

The alternatives I’ve identified are public_configs and all_dependent_configs. Neither is completely correct:

public_configs can expose “ldflags” to targets that directly depend on the static_library or source_set, but there’s no guarantee that those targets themselves are linker output. Furthermore, in a target that’s switchable between linker output and non-linker output, such as a Chromium “component”, the ldflags ought to be effective on the target itself, and NOT on any dependent.

all_dependent_configs exposes a config broadly to all dependents, which similarly is not appropriate.

Here’s an example of where this came up: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/833408/3/snapshot/BUILD.gn#249. snapshot_test is a source_set whose elf/elf_image_reader_test.cc requires custom ldflags of -Wl,--dynamic-list,elf/test_exported_symbols.sym. Because it’s a source_set, no link is performed. The ldflags need to be pushed to whatever dependent target performs a link step. In this case, we’re lucky in that the two targets that do this are in fact both direct dependents, but in other situations, we may not be as lucky.

https://groups.google.com/a/chromium.org/d/topic/gn-dev/g7LGN2aIL-Q has some history. Unfortunately, this means that “ldflags” is entirely anemic in targets that aren’t linker output, and there isn’t really any proper way to push ldflags down to (possibly indirect) dependent targets that do produce linker output.