From https://chromium-review.googlesource.com/c/chromium/src/+/849414 PS#5, which changes module boundaries

We end up in the situation where:
- component A (namely //gpu) defines some crash keys (in https://cs.chromium.org/chromium/src/gpu/config/gpu_crash_keys.h?q=gpu/config/gpu_crash_keys.h&sq=package:chromium&dr&l=29 , properly exported with the GPU_EXPORT macro)
- component B (namely //gpu/ipc:gl_in_process_context) sets those crash keys (in https://cs.chromium.org/chromium/src/gpu/ipc/in_process_command_buffer.cc?sq=package:chromium&dr&l=453 )

Even though A properly (publicly) depends on //components/crash/core/common:crash_key, and B depends on A, we end up with link errors on Windows and Mac. e.g.:

FAILED: gl_in_process_context.dll gl_in_process_context.dll.lib gl_in_process_context.dll.pdb 
E:/b/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x86 False link.exe /nologo /IMPLIB:./gl_in_process_context.dll.lib /DLL /OUT:./gl_in_process_context.dll /PDB:./gl_in_process_context.dll.pdb @./gl_in_process_context.dll.rsp
in_process_command_buffer.obj : error LNK2019: unresolved external symbol "public: void __thiscall crashpad::Annotation::SetSize(unsigned int)" (?SetSize@Annotation@crashpad@@QAEXI@Z) referenced in function "public: void __thiscall crashpad::StringAnnotation<4>::Set(char const *)" (?Set@?$StringAnnotation@$03@crashpad@@QAEXPBD@Z)
./gl_in_process_context.dll : fatal error LNK1120: 1 unresolved externals

The reason is that on win/mac crash_keys is a static library which links to //third_party/crashpad/crashpad/client, but gets called from inline templates from CrashKeyString::Set, but public_deps on static libraries don't propagate. The suggested workaround is to explicitly pull //components/crash/core/common:crash_key in component B.

So 2 things:
1- it's somewhat annoying and user-unfriendly to have to pull static libraries as a dependency out of nowhere (there is nothing obvious at the call site that suggests it might be necessary). This is somewhat aggravated by the fact that on other platforms (Linux/Android), crash_key is a component and so things work as expected
2- statically linking crashpad/client means duplicating globals per-component, among others the AnnotationList and we get into odd situations where a given CrashKeyString (aka StringAnnotation) can only be part of a single AnnotationList, and so setting a given CrashKeyString from 2 different components will kind of work (the annotation will be registered in the component that first sets it), but things like GetCrashKeyValue would not work properly.


I believe one way out would be to make crashpad/client a component. I don't see anything obvious that would break, but I don't know that code very well. An alternative could be to make crash_key a component, but either way crashpad/client symbols that are exposed publicly (e.g. crashpad::Annotation::SetSize) would need to be exported.