I think this is the same issue you'd have with any other kind of object file that is included into multiple shared libraries. The correct answer is, don't do that.

Though perhaps GN should be smart enough to warn about this ...

rsesek@, I think this one is yours.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/73d41be15a231987117bd4e932219de569f37a9c

commit 73d41be15a231987117bd4e932219de569f37a9c
Author: rsesek <rsesek@chromium.org>
Date: Wed Jun 15 16:33:55 2016

[Mac/GN] Make //components/crash/core/common a static_library.

On Mac, if it is a source_set, error messages like this will be printed, since
the .o file ends up in multiple targets:

objc[56710]: Class CrZombie is implemented in both /Volumes/Build/src/out/shared/./libsessions.dylib and
    /Volumes/Build/src/out/shared/libchrome_dll.dylib. One of the two will be used.
    Which one is undefined.

BUG= 611894 
R=mark@chromium.org

Review-Url: https://codereview.chromium.org/2069543006
Cr-Commit-Position: refs/heads/master@{#399922}

[modify] https://crrev.com/73d41be15a231987117bd4e932219de569f37a9c/components/crash/core/common/BUILD.gn

objc[19048]: Class MockCrApp is implemented in both /Volumes/Build/src/out/shared/libtest_runner.dylib and /Volumes/Build/src/out/shared/Content Shell.app/Contents/Frameworks/Content Shell Framework.framework/Content Shell Framework. One of the two will be used. Which one is undefined.
objc[19048]: Class CocoaTestHelperWindow is implemented in both /Volumes/Build/src/out/shared/libtest_runner.dylib and /Volumes/Build/src/out/shared/Content Shell.app/Contents/Frameworks/Content Shell Framework.framework/Content Shell Framework. One of the two will be used. Which one is undefined.

Is there actually anything to do here in GN itself? Or is this more an issue that we have badly defined targets in some cases?

Does fixing this need to block anything?

As suggested by laforge@ and a conversation w/ the monorail folks, I'm going to try tracking GN-Migration related issues by *just* using the Proj-GN-Migration label, and not using blocking/rollup bugs, so that we can use blocking for just tasks that truly need to be completed before other tasks can make progress.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d295e88072c54f74421d8d9ba3dff50d6d5c9a0d

commit d295e88072c54f74421d8d9ba3dff50d6d5c9a0d
Author: sdy <sdy@chromium.org>
Date: Wed Jul 13 23:53:33 2016

Componentize zombies to silence ObjC runtime errors in component builds

With //components/crash/core/common as a static library, its classes can
end up in multiple components and frustrate the ObjC runtime:

    objc[82840]: Class CrZombie is implemented in both /b/swarm_slave/work/isolated/runpsh5q4/out/Debug/./libsessions.dylib and /b/swarm_slave/work/isolated/runpsh5q4/out/Debug/libchrome_dll.dylib. One of the two will be used. Which one is undefined.
    objc[82840]: Class CrFatZombie is implemented in both /b/swarm_slave/work/isolated/runpsh5q4/out/Debug/./libsessions.dylib and /b/swarm_slave/work/isolated/runpsh5q4/out/Debug/libchrome_dll.dylib. One of the two will be used. Which one is undefined.

Making the implementation its own component stops this.

(rsesek@chromium.org did all of the thinking on this — my main
contribution was getting tired enough of the warnings to grab him.)

BUG= 611894 
TEST=Build Chromium for Mac with gn and `is_component_build = true`, run it from a terminal, and look for warnings like the above.

Review-Url: https://codereview.chromium.org/2148803003
Cr-Commit-Position: refs/heads/master@{#405351}

[modify] https://crrev.com/d295e88072c54f74421d8d9ba3dff50d6d5c9a0d/components/crash/core/common/BUILD.gn
[add] https://crrev.com/d295e88072c54f74421d8d9ba3dff50d6d5c9a0d/components/crash/core/common/crash_export.h
[modify] https://crrev.com/d295e88072c54f74421d8d9ba3dff50d6d5c9a0d/components/crash/core/common/objc_zombie.h

Is this still an issue?

I think it's mostly resolved.