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

[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

[Robert Sesek, 2016-06-22 20:17:25]

Description was changed from

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

The 10.11 SDK has an incompatibility with a macOS 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
==========

to

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

The 10.11 SDK has an incompatibility with a macOS 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
==========

[Mark Mentovai, 2016-06-22 21:09:06]

LGTM

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn
File gpu/ipc/service/BUILD.gn (right):

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn#ne...
gpu/ipc/service/BUILD.gn:1: # Copyright 2016 The Chromium Authors. All rights
reserved.
CL description: OS X 10.7. It’s not macOS ’til 10.12.

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn#ne...
gpu/ipc/service/BUILD.gn:2: # Use of this source code is governed by a BSD-style
license that can be
Do we have a bug to update the DT to 10.8 or higher? If so, hang a note there
about undoing this. If not, revise these TODOs to say that the hackaround can be
removed when the DT is updated to or past that level.

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn#ne...
gpu/ipc/service/BUILD.gn:81: "ApplicationServices.framework",  # Temporary hack
around https://crbug.com/620127.
>80 OK in .gn?

[Robert Sesek, 2016-06-22 22:03:40]

Description was changed from

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

The 10.11 SDK has an incompatibility with a macOS 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
==========

to

==========
[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
==========

[Robert Sesek, 2016-06-22 22:13:43]

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn
File gpu/ipc/service/BUILD.gn (right):

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn#ne...
gpu/ipc/service/BUILD.gn:1: # Copyright 2016 The Chromium Authors. All rights
reserved.
On 2016/06/22 21:09:05, Mark Mentovai wrote:
> CL description: OS X 10.7. It’s not macOS ’til 10.12.

Done.

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn#ne...
gpu/ipc/service/BUILD.gn:2: # Use of this source code is governed by a BSD-style
license that can be
On 2016/06/22 21:09:05, Mark Mentovai wrote:
> Do we have a bug to update the DT to 10.8 or higher? If so, hang a note there
> about undoing this. If not, revise these TODOs to say that the hackaround can
be
> removed when the DT is updated to or past that level.

Nico just filed https://crbug.com/622481. Updated.

https://codereview.chromium.org/2092513002/diff/1/gpu/ipc/service/BUILD.gn#ne...
gpu/ipc/service/BUILD.gn:81: "ApplicationServices.framework",  # Temporary hack
around https://crbug.com/620127.
On 2016/06/22 21:09:05, Mark Mentovai wrote:
> >80 OK in .gn?

GN format didn't complain. Putting the comment above causes weird formatting, so
I'll just do this.

[commit-bot: I haz the power, 2016-06-22 23:32:56]

Description was changed from

==========
[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
==========

to

==========
[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://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c
Cr-Commit-Position: refs/heads/master@{#401458}
==========

[commit-bot: I haz the power, 2016-06-22 23:32:57]

Patchset 2 (id:??) landed as
https://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c
Cr-Commit-Position: refs/heads/master@{#401458}

[Robert Sesek, 2016-06-22 23:34:26]

Description was changed from

==========
[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://crrev.com/5f7bc190c7ffeda2a2c56161b371bc16750fac2c
Cr-Commit-Position: refs/heads/master@{#401458}
==========

to

==========
[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/+/5f7bc190c7ffeda2a2c56161b371...
==========

[Robert Sesek, 2016-06-22 23:34:27]

Committed patchset #2 (id:20001) manually as
5f7bc190c7ffeda2a2c56161b371bc16750fac2c (presubmit successful).

[Robert Sesek, 2016-06-30 20:22:49]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/2118563002/ by rsesek@chromium.org.

The reason for reverting is: After https://crrev.com/42e3c3e7125d the build
warns if it detects this incompatibility..