I can't repro this on a fresh build at ee1625aec7914ec74c615da9b7d7b98df42cca11.

[mac triage] zea@ - is this still happening? (maybe an xcode upgrade happened which could break a build dir more than ninja can track).

Yep, this still happens for me, even after blowing away out/Default and doing another gn gen out/Default.

Any suggestions on how to debug this?

(FYI I synced up to 8d2df66d2b150b00ed046d809bd0a16b0a7b75b7, r400629) before trying again.

Thank you for providing more feedback. Adding requester "tapted@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Can you get the output of `otool -L out/Default/libskia.dylib` ?

Do you have any local modifications to Skia?

I am suffering this too. Raise it to pri-2 as this is blocking some of us doing anything on Mac.

My gn args:

is_component_build = true
is_debug = false
enable_nacl = false
symbol_level = 0
use_goma = true
dcheck_always_on = true

xcode version: 7.2.1 (7C1002)
SDK version: 10.11

Seems to be related to the 10.11 SDK.

Any suggestions what I can do before this is fixed?  Switching back to gyp?

You can install the 10.10 SDK: go/mac-10.10-sdk

I think this is related to the .tbd files in the 10.11 framework. 

% cd /SDKs/MacOSX10.11.sdk/System/Library/Frameworks 
% less ApplicationServices.framework/ApplicationServices.tbd
archs:           [ i386, x86_64 ]
platform:        macosx
install-name:    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
current-version: 48.0
[snip]
    re-exports:      [ /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS, 
                       /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync, 
                       /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices, 
                       /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis, 
                       /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore, 
                       /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD, 
                       /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis, 
                       /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics, 
                       /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices, 
                       /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText, 
                       /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO ]

% less CoreGraphics.framework/CoreGraphics.tbd
archs:           [ i386, x86_64, x86_64h ]
platform:        macosx
install-name:    /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
current-version: 600.0
compatibility-version: 64.0

% gn desc out/gn2 //skia libs
    AppKit.framework
    CoreFoundation.framework
    CoreGraphics.framework
    CoreText.framework
    Foundation.framework

% otool -L out/gn2/libskia.dylib                  
out/gn2/libskia.dylib:
	@rpath/libskia.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.32.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 64.0.0, current version 600.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1256.1.0)
	@rpath/libbase.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libicuuc.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

It looks like the linker is converting //skia's dependency on CoreGraphics.framework to be on ApplicationServices.framework, but it's taking the wrong compatibility version. Note that in the .tbd files, ApplicationServices has version 48.0 and CoreGraphics has 64.0. But in the otool output, ApplicationServices has a compatibility version of 64.0!

Temporary workaround will be to link against ApplicationServices instead of CoreGraphics. Will also try and reduce a testcase.

I was able to create a reduced testcase. It seems to be an incompatibility between our usage of -mmacosx-version-min=10.7 and the 10.11 SDK.

Building `make test` (repro of problem) will result in the incompatible version error above, but both `make test-as` (link against ApplicationServices) and `make test-108` (mmacox-version-min=10.8) do not have the issue.

Deleted: Makefile 528 bytes

Makefile 528 bytes View Download

Deleted: test.cc 132 bytes

test.cc 132 bytes View Download

If you specify `-framework ApplicationServices -framework CoreGraphics -mmacosx-version-min=10.7` that also resolves the issue.

I'll add ApplicationServices to the libs list wherever we have CoreGraphics.

Do the link lines have AS at all or is it just CG?

Does the ordering of AS and CG on the link line relative to one another
matter?

In #15 above, the link line only has CoreGraphics. Somehow ApplicationService's reexporting is confusing the compatibility version, though.

If you have both AS and CG on the libs list, then ordering does matter and AS has to come first.

It’s picking up ApplicationServices instead of CoreGraphics because CoreGraphics has this symbol: $ld$install_name$os10.7$/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices. It also has that symbol for os10.4-os10.6. This explains why the problem disappears with a DT higher than 10.7.

When one of these funny $ld$install_name symbols shows up, it influences ld’s use of the install_name as placed into an LC_LOAD_DYLIB command. It doesn’t actually cause ld to look at the library given as the new install_name (ApplicationServices), so nothing picks up that library’s actual version information. Normally, the versions provided by the original library (CoreGraphics) are used.

Xcode 7.2 ld64-253.9/src/ld/parsers/macho_dylib_file.cpp mach_o::dylib::File<>::addSymbol() cites radar 14448206 with a workaround for this problem: it sets ApplicationServices’ compatibility version to 1.0.

ld64-253.9/src/ld/parsers/textstub_dylib_file.cpp textstub::dylib::File<>::addSymbol() does not have this workaround, so CoreGraphics’ version information gets carried to an LC_LOAD_DYLIB command that references ApplicationServices instead. This occurs with the 10.11 SDK (which uses .tbd files instead of Mach-O dylibs) and a DT of 10.7 or lower (due to the ld$install_name$os symbols present in CoreGraphics).

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

commit 5f7bc190c7ffeda2a2c56161b371bc16750fac2c
Author: Robert Sesek <rsesek@chromium.org>
Date: Wed Jun 22 23:27:44 2016

[Mac/GN] Explicitly link ApplicationServices wherever CoreGraphics is linked.

The 10.11 SDK has an incompatibility with a OS X 10.7 deployment target.
ApplicationServices re-exports CoreGraphics, but due to a bug, the dylib
compatibility version from the re-exported framework gets confused with
the version of the framework doing the re-export.

This only manifests itself in the component build because individual
components depend on CoreGraphics directly instead of ApplicationServices.
In the static library build, the transitive collection of libs ensures that
ApplicationServices gets linked before CoreGraphics when linking the
Chromium Framework, so this doesn't occur.

To hack around the issue, specify ApplicationServices in libs ahead of
CoreGraphics so that the correct compatibility version is picked up. After
the deployment is updated to 10.8+ ( https://crbug.com/580152 ) these hacks
can be removed.

BUG= 620127 
R=mark@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

Review URL: https://codereview.chromium.org/2092513002 .

Cr-Commit-Position: refs/heads/master@{#401458}

[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/gpu/ipc/service/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/media/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/media/capture/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/skia/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/ui/accelerated_widget_mac/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/ui/display/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/ui/gfx/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/ui/native_theme/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/ui/snapshot/BUILD.gn
[modify] https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c/ui/views/BUILD.gn

This bug is already fixed in ld64-264.3.102 from Xcode 7.3.1. (It may have been fixed in 7.2.1 or 7.3, my money’s on 7.3.)

The source code for this version of ld isn’t available publicly yet, but I can see that the code responsible for interpreting $ld$install_name$ symbols has moved to the new generic::dylib::File<>::addSymbol() method, which is referenced by both mach_o::dylib::File<>::addSymbol() and textstub::dylib::File<>::addSymbol().

Anyone seeing this bug should upgrade to the latest version of Xcode, 7.3.1. I think that we can revert the workaround in 5f7bc190c7ff.

I'd like to keep the workaround as I think there are probably many developers using older Xcode.

I think we can have GN print a message if the SDK is 10.11 and the Xcode is <7.3.1. Then we can safely revert.

I can confirm that this is broken in Xcode 7.2.1 7C1002 with ld64-253.9, and fixed in Xcode 7.3 7D175 with ld64-264.3.101.

We may add a warning for this here: https://codereview.chromium.org/2094693002/

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

commit 42e3c3e7125d71393abb461ff00242a8d2d8aa57
Author: rsesek <rsesek@chromium.org>
Date: Wed Jun 29 23:06:37 2016

[Mac/GN] Assert if the SDK version is 10.11 but Xcode is <7.3.

There is a known incompatibility when using the 10.11 SDK and Xcode 7.2

BUG= 620127 
R=mark@chromium.org,dpranke@chromium.org

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

[modify] https://crrev.com/42e3c3e7125d71393abb461ff00242a8d2d8aa57/build/config/mac/mac_sdk.gni

I'm going to try tracking ship-blocking things via the label "Proj-GN-Migration-Ship" (instead of Proj-GN-Migration) as suggested w/ a conversation w/ laforge@ and the monorail folks a while ago.

Querying for "Proj=GN-Migration%" should still return bugs for both labels, and this will allow us to filter out rollup things more easily, so that we can use blocking just for things that are truly blocking other bugs.

Also, closing this (again).

Not yet :D, I'm reverting the original hack.

ah, okay :).

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

commit ac799c2fd50b8fb62b7a8186ff78b025de5b8718
Author: rsesek <rsesek@chromium.org>
Date: Fri Jul 01 02:18:47 2016

Revert of [Mac/GN] Explicitly link ApplicationServices wherever CoreGraphics is linked. (patchset #2 id:20001 of https://codereview.chromium.org/2092513002/ )

Reason for revert:
After https://crrev.com/42e3c3e7125d the build warns if it detects this incompatibility.

Original issue's description:
> [Mac/GN] Explicitly link ApplicationServices wherever CoreGraphics is linked.
>
> The 10.11 SDK has an incompatibility with a OS X 10.7 deployment target.
> ApplicationServices re-exports CoreGraphics, but due to a bug, the dylib
> compatibility version from the re-exported framework gets confused with
> the version of the framework doing the re-export.
>
> This only manifests itself in the component build because individual
> components depend on CoreGraphics directly instead of ApplicationServices.
> In the static library build, the transitive collection of libs ensures that
> ApplicationServices gets linked before CoreGraphics when linking the
> Chromium Framework, so this doesn't occur.
>
> To hack around the issue, specify ApplicationServices in libs ahead of
> CoreGraphics so that the correct compatibility version is picked up. After
> the deployment is updated to 10.8+ ( https://crbug.com/580152 ) these hacks
> can be removed.
>
> BUG= 620127 
> R=mark@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
>
> Committed: https://chromium.googlesource.com/chromium/src/+/5f7bc190c7ffeda2a2c56161b371bc16750fac2c

TBR=mark@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 620127 

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

[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/gpu/ipc/service/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/media/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/media/capture/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/skia/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/ui/accelerated_widget_mac/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/ui/display/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/ui/gfx/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/ui/native_theme/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/ui/snapshot/BUILD.gn
[modify] https://crrev.com/ac799c2fd50b8fb62b7a8186ff78b025de5b8718/ui/views/BUILD.gn

% gn gen out/gn2
********************************************************************************
 WARNING: The Mac OS X SDK is incompatible with the version of Xcode. To fix,
          either upgrade Xcode to the latest version or install the Mac OS X
          10.10 SDK. For more information, see  https://crbug.com/620127 .

 Current SDK Version:   10.11
 Current Xcode Version: 0721 (7C1002)
********************************************************************************
ERROR at //build/config/mac/mac_sdk.gni:77:3: Assertion failed.
  assert(false, "SDK is incompatible with Xcode")
  ^-----
SDK is incompatible with Xcode
See //build/config/sysroot.gni:85:3: whence it was imported.
  import("//build/config/mac/mac_sdk.gni")
  ^--------------------------------------
See //base/BUILD.gn:25:1: whence it was imported.
import("//build/config/sysroot.gni")
^----------------------------------
See //BUILD.gn:178:5: which caused the file to be included.
    "//base:base_unittests",
    ^----------------------

This is great!