Make media/capture gn and gyps produce components

Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using
ImageCapture types.

This basically reproduces the media/cast and media/midi
structure.

Windows import/export issues made necessary to add
capture_export and associated CAPTURE_EXPORT macro,
again, replicating media/midi.

gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make
them explicit (e.g. media:gpu).

BUG=518807
Committed: https://crrev.com/f4683c359791bb0264cddddeca6b8bcae0e61817
Cr-Commit-Position: refs/heads/master@{#399024}

[mcasas, 2016-06-02 21:02:53]

Description was changed from

==========
media/capture gn and gyps producing components

BUG=
==========

to

==========
[WIP]  media/capture gn and gyps producing components

BUG=
==========

[mcasas, 2016-06-03 04:47:12]

Description was changed from

==========
[WIP]  media/capture gn and gyps producing components

BUG=
==========

to

==========
[WIP]  media/capture gn and gyps producing components


gn gen ... --check uncovered some transitive dependencies
during the "anayze" phase of the bots. Made them explicit.

BUG=518807
==========

[mcasas, 2016-06-04 00:32:46]

Patchset #1 (id:1) has been deleted

[mcasas, 2016-06-04 00:32:55]

Patchset #1 (id:20001) has been deleted

[mcasas, 2016-06-04 00:33:03]

Patchset #1 (id:40001) has been deleted

[mcasas, 2016-06-04 00:33:15]

Patchset #1 (id:60001) has been deleted

[mcasas, 2016-06-04 00:33:29]

Patchset #1 (id:80001) has been deleted

[mcasas, 2016-06-04 00:33:39]

Patchset #1 (id:100001) has been deleted

[mcasas, 2016-06-04 00:33:50]

Patchset #1 (id:120001) has been deleted

[mcasas, 2016-06-04 00:33:59]

Patchset #1 (id:140001) has been deleted

[mcasas, 2016-06-04 00:34:08]

Patchset #1 (id:160001) has been deleted

[mcasas, 2016-06-06 16:33:04]

Patchset #4 (id:240001) has been deleted

[mcasas, 2016-06-07 18:08:30]

Patchset #1 (id:180001) has been deleted

[mcasas, 2016-06-07 18:08:39]

Patchset #1 (id:200001) has been deleted

[mcasas, 2016-06-07 18:08:51]

Patchset #1 (id:220001) has been deleted

[mcasas, 2016-06-07 18:09:01]

Patchset #1 (id:260001) has been deleted

[mcasas, 2016-06-07 18:09:09]

Patchset #1 (id:280001) has been deleted

[mcasas, 2016-06-07 18:09:17]

Patchset #1 (id:300001) has been deleted

[mcasas, 2016-06-07 18:26:37]

Description was changed from

==========
[WIP]  media/capture gn and gyps producing components


gn gen ... --check uncovered some transitive dependencies
during the "anayze" phase of the bots. Made them explicit.

BUG=518807
==========

to

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using 
ImageCapture types. 

This basically reproduces the media/cast and media/midi
structure. 

gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make 
them explicit.

BUG=518807
==========

[mcasas, 2016-06-07 18:49:11]

Patchset #2 (id:340001) has been deleted

[mcasas, 2016-06-07 19:02:32]

mcasas@chromium.org changed reviewers:
+ miu@chromium.org, xhwang@chromium.org

[mcasas, 2016-06-07 19:02:33]

xhwang@, miu@, PTAL

(please ignore Win bot failure, seems like
I'm double linking mf_initializer, will soon
work on it on a Win laptop)

[xhwang, 2016-06-07 19:47:15]

I like this approach in general! I have some comments though.

https://codereview.chromium.org/2031073002/diff/360001/media/BUILD.gn
File media/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/BUILD.gn#newcode775
media/BUILD.gn:775: "//media/capture",
Looks like this is not required by any of the "sources" above. What's the
purpose of this deps? Should the test code depend on //media/capture directly?

https://codereview.chromium.org/2031073002/diff/360001/media/base/BUILD.gn
File media/base/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/base/BUILD.gn#ne...
media/base/BUILD.gn:490: "//media/capture/video/android",
OOC, which test requires this?

https://codereview.chromium.org/2031073002/diff/360001/media/capture/BUILD.gn
File media/capture/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/capture/BUILD.gn...
media/capture/BUILD.gn:82: "//media/base",
media/base is a source_set, will this cause the media/base files to be linked
statically into "capture" target? Is the deps on "media" sufficient?

https://codereview.chromium.org/2031073002/diff/360001/media/capture/BUILD.gn...
media/capture/BUILD.gn:154: "//media/base:unittests",
OOC, why capture unittests need to depend on //media/base:unittests?

https://codereview.chromium.org/2031073002/diff/360001/media/gpu/BUILD.gn
File media/gpu/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/gpu/BUILD.gn#new...
media/gpu/BUILD.gn:337: public_deps += [ "//media/base/win" ]
Can you comment why this needs to be a public_deps?

[miu, 2016-06-07 21:13:19]

xhwang@ seems to have covered my concerns. Here are two other things:

https://codereview.chromium.org/2031073002/diff/360001/media/capture/capture.gyp
File media/capture/capture.gyp (right):

https://codereview.chromium.org/2031073002/diff/360001/media/capture/capture....
media/capture/capture.gyp:157: 'target_name': 'unittests',
Should this target name be capture_unittests?

Also, if the unit tests are being moved to a new target, you'll need to add all
the bot config changes to make sure this test binary is run in the CQ and the
build waterfall. In other words, checking in these build files changes as-is
will automatically disable all the media/capture tests!

[mcasas, 2016-06-07 22:02:58]

Patchset #1 (id:320001) has been deleted

[mcasas, 2016-06-07 23:18:43]

Patchset #3 (id:400001) has been deleted

[mcasas, 2016-06-07 23:19:29]

Comments addressed, PTAL

(except Win build troubles, that I'll address tomorrow)

https://codereview.chromium.org/2031073002/diff/360001/media/BUILD.gn
File media/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/BUILD.gn#newcode775
media/BUILD.gn:775: "//media/capture",
On 2016/06/07 19:47:15, xhwang wrote:
> Looks like this is not required by any of the "sources" above. What's the
> purpose of this deps? Should the test code depend on //media/capture directly?


base/run_all_unittests.cc calls RegisterCaptureJni()
which is defined in capture/video/android/BUILD.gn,
and that in turn needs the rest of capture. 

But is true that it shouldn't be here, so instead
I'm adding this provision, for android only, in the
media/base:test_support.

Note that at least two targets, namely
audio_unittests and ffmpeg_regression_tests,
explicitly pull base/run_all_unittests.cc and then
add as dependency base:test_support, maybe
the latter target should include the said file?

https://codereview.chromium.org/2031073002/diff/360001/media/base/BUILD.gn
File media/base/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/base/BUILD.gn#ne...
media/base/BUILD.gn:490: "//media/capture/video/android",
On 2016/06/07 19:47:15, xhwang wrote:
> OOC, which test requires this?

There isn't capture_unittests per se, they are 
hanging from the media_unittests and they 
explicitly call the Register...Jni() [1]

[1]
https://cs.chromium.org/chromium/src/media/base/run_all_unittests.cc?q=regist...

However, I'm adding this explicit dependency
for Android to test_support, so this one is not
needed, removed.

https://codereview.chromium.org/2031073002/diff/360001/media/capture/BUILD.gn
File media/capture/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/capture/BUILD.gn...
media/capture/BUILD.gn:82: "//media/base",
On 2016/06/07 19:47:15, xhwang wrote:
> media/base is a source_set, will this cause the media/base files to be linked
> statically into "capture" target? 

Hmm I'm not sure, but i think the component
builds would have failed with duplicate symbols
in this case, right?

> Is the deps on "media" sufficient?

It is. Removed //media/base explicit dep.

https://codereview.chromium.org/2031073002/diff/360001/media/capture/BUILD.gn...
media/capture/BUILD.gn:154: "//media/base:unittests",
On 2016/06/07 19:47:15, xhwang wrote:
> OOC, why capture unittests need to depend on //media/base:unittests?

Before, capture_unittests was a source set that
needed capture, and it was the latter that needed
media/base, but now capture is a component, so
this dependency is not needed, removed.

https://codereview.chromium.org/2031073002/diff/360001/media/capture/capture.gyp
File media/capture/capture.gyp (right):

https://codereview.chromium.org/2031073002/diff/360001/media/capture/capture....
media/capture/capture.gyp:157: 'target_name': 'unittests',
On 2016/06/07 21:13:18, miu (OOO June 11-19) wrote:
> Should this target name be capture_unittests?
>

As you wish. When included, it is called
'capture/capture.gyp:unittests',
which I think is explicit enough.
 
> Also, if the unit tests are being moved to a new target, you'll need to add
all
> the bot config changes to make sure this test binary is run in the CQ and the
> build waterfall. In other words, checking in these build files changes as-is
> will automatically disable all the media/capture tests!

I didn't want to create a new capture_unittests butl
keep them inside media_unittests: I don't think the former
have enough entity, manpower or necessity to be run 
on their own (with all the necessary .isolates, infra etc)
that you mention...

What I think I managed here is to have a bunch of 
sources (see the type: 'none' in the line below) that are
melted into media_unittests. (Confirmed on my
Mac gyp build).

https://codereview.chromium.org/2031073002/diff/360001/media/gpu/BUILD.gn
File media/gpu/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/360001/media/gpu/BUILD.gn#new...
media/gpu/BUILD.gn:337: public_deps += [ "//media/base/win" ]
On 2016/06/07 19:47:15, xhwang wrote:
> Can you comment why this needs to be a public_deps?

On ToT, gpu depends on media which has capture 
inside, but when taking out capture of media, 
gn --check said that gpu was transitively depending
on media/base/win, concretely on mf_initialize, that
is used on the dxva...win files.

However I'm still trying to get this fully corrected, as
not all Win bots are happy, some see mf_initializer
defined twice.

[mcasas, 2016-06-08 19:03:08]

Got windows building, PTAL.

[mcasas, 2016-06-09 00:18:38]

Description was changed from

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using 
ImageCapture types. 

This basically reproduces the media/cast and media/midi
structure. 

gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make 
them explicit.

BUG=518807
==========

to

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using 
ImageCapture types. 

This basically reproduces the media/cast and media/midi
structure. 

Windows import/export issues made necessary to add
capture_export and associated CAPTURE_EXPORT macro,
again, replicating media/midi. 


gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make 
them explicit (e.g. media:gpu).

BUG=518807
==========

[mcasas, 2016-06-09 00:32:32]

Patchset #4 (id:440001) has been deleted

[mcasas, 2016-06-09 01:08:52]

Patchset #5 (id:480001) has been deleted

[mcasas, 2016-06-09 01:11:58]

Patchset #5 (id:500001) has been deleted

[xhwang, 2016-06-09 06:30:46]

https://chromiumcodereview.appspot.com/2031073002/diff/520001/media/base/BUIL...
File media/base/BUILD.gn (right):

https://chromiumcodereview.appspot.com/2031073002/diff/520001/media/base/BUIL...
media/base/BUILD.gn:409: ]
Now media/capture is a separate target, we probably should also have a separate
media_capture_unittest target. Then we shouldn't need this here. How about a
TODO and fix it in a followup CL?

https://chromiumcodereview.appspot.com/2031073002/diff/520001/media/base/win/...
File media/base/win/BUILD.gn (right):

https://chromiumcodereview.appspot.com/2031073002/diff/520001/media/base/win/...
media/base/win/BUILD.gn:7: component("win") {
Why is this change necessary and be part of this CL?

media:media_implementation should only be used by the "media" target (including
source_sets that are part of the "media" component). Otherwise, since
mf_initializer.h uses MEDIA_EXPORT, it could cause trouble (especially on
windows bots) if we ever have files in the "media" target include
mf_initializer.h.

If you really want to make this a component, then we need a new EXPORT, e.g.
MEDIA_WIN_EXPORT, similar to the new CAPURE_EXPORT you added in this CL.

[mcasas, 2016-06-09 16:07:55]

guys PTAL

https://codereview.chromium.org/2031073002/diff/520001/media/base/BUILD.gn
File media/base/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/520001/media/base/BUILD.gn#ne...
media/base/BUILD.gn:409: ]
On 2016/06/09 06:30:46, xhwang wrote:
> Now media/capture is a separate target, we probably should also have a
separate
> media_capture_unittest target. Then we shouldn't need this here. How about a
> TODO and fix it in a followup CL?

Done.

https://codereview.chromium.org/2031073002/diff/520001/media/base/win/BUILD.gn
File media/base/win/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/520001/media/base/win/BUILD.g...
media/base/win/BUILD.gn:7: component("win") {
On 2016/06/09 06:30:46, xhwang wrote:
> Why is this change necessary and be part of this CL?

It is necessary because capture.dll depends on 
this, and so does media/gpu.dll (via 
media/gpu/dxva_video_decode_accelerator_win.cc)
and since now they're each in their own DLL,
I would get linking errors if I don't make
it itself imported for both. This problem
wasn't such before, as there was just
media.dll.

> 
> media:media_implementation should only be used by the "media" target
(including
> source_sets that are part of the "media" component). Otherwise, since
> mf_initializer.h uses MEDIA_EXPORT, it could cause trouble (especially on
> windows bots) if we ever have files in the "media" target include
> mf_initializer.h.
> 
> If you really want to make this a component, then we need a new EXPORT, e.g.
> MEDIA_WIN_EXPORT, similar to the new CAPTURE_EXPORT you added in this CL.

I guess I have to bite the bullet then! :)

[xhwang, 2016-06-09 16:11:58]

LGTM % one last comment

https://codereview.chromium.org/2031073002/diff/540001/media/base/win/BUILD.gn
File media/base/win/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/540001/media/base/win/BUILD.g...
media/base/win/BUILD.gn:7: component("win") {
Just in case, would it work if this is a source_set(), given this target is so
small. Then we don't need to worry about the EXPORT.

[mcasas, 2016-06-09 16:45:22]

mcasas@chromium.org changed reviewers:
+ avi@chromium.org

[mcasas, 2016-06-09 16:45:23]

avi@ Owners RS for the content/ build files please.

https://codereview.chromium.org/2031073002/diff/540001/media/base/win/BUILD.gn
File media/base/win/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/540001/media/base/win/BUILD.g...
media/base/win/BUILD.gn:7: component("win") {
On 2016/06/09 16:11:58, xhwang wrote:
> Just in case, would it work if this is a source_set(), given this target is so
> small. Then we don't need to worry about the EXPORT.

Negative:

$ time ninja -j 100 -C out/gn capture
ninja: Entering directory `out/gn'
[1/1] LINK(DLL) capture.dll capture.dll.lib
FAILED: C:/python_27_amd64/files/python.exe gyp-win-tool link-wrapper
environment.x64 False link.exe /nologo /IMPLIB:./capture.dll.lib /DLL
/OUT:./capture.dll /PDB:./capture.dll.pdb @./capture.dll.rsp
media.dll.lib(media.dll) : error LNK2005: "void __cdecl
media::InitializeMediaFoundation(void)"
(?InitializeMediaFoundation@media@@YAXXZ) already defined in mf_initializer.obj
./capture.dll : fatal error LNK1169: one or more multiply defined symbols found
ninja: build stopped: subcommand failed.

[mcasas, 2016-06-09 17:22:09]

Patchset #7 (id:560001) has been deleted

[xhwang, 2016-06-09 17:28:57]

https://codereview.chromium.org/2031073002/diff/540001/media/base/win/BUILD.gn
File media/base/win/BUILD.gn (right):

https://codereview.chromium.org/2031073002/diff/540001/media/base/win/BUILD.g...
media/base/win/BUILD.gn:7: component("win") {
On 2016/06/09 16:45:23, mcasas wrote:
> On 2016/06/09 16:11:58, xhwang wrote:
> > Just in case, would it work if this is a source_set(), given this target is
so
> > small. Then we don't need to worry about the EXPORT.
> 
> Negative:
> 
> $ time ninja -j 100 -C out/gn capture
> ninja: Entering directory `out/gn'
> [1/1] LINK(DLL) capture.dll capture.dll.lib
> FAILED: C:/python_27_amd64/files/python.exe gyp-win-tool link-wrapper
> environment.x64 False link.exe /nologo /IMPLIB:./capture.dll.lib /DLL
> /OUT:./capture.dll /PDB:./capture.dll.pdb @./capture.dll.rsp
> media.dll.lib(media.dll) : error LNK2005: "void __cdecl
> media::InitializeMediaFoundation(void)"
> (?InitializeMediaFoundation@media@@YAXXZ) already defined in
mf_initializer.obj
> ./capture.dll : fatal error LNK1169: one or more multiply defined symbols
found
> ninja: build stopped: subcommand failed.

fair enough. I hit something similar before. I like the idea of "component", but
hate the EXPORT part :(

[Avi (use Gerrit), 2016-06-09 18:00:06]

content GN files LGTM

[miu, 2016-06-09 19:13:23]

lgtm. Confirmed my last round of comments were just my own misunderstanding
about the organization of the build. ;-)

[mcasas, 2016-06-09 19:21:16]

The CQ bit was checked by mcasas@chromium.org

[mcasas, 2016-06-09 19:21:17]

The patchset sent to the CQ was uploaded after l-g-t-m from xhwang@chromium.org
Link to the patchset: https://codereview.chromium.org/2031073002/#ps580001
(title: "Added again 'Android missed dep' PS5")

[commit-bot: I haz the power, 2016-06-09 19:21:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2031073002/580001

[commit-bot: I haz the power, 2016-06-09 21:35:25]

Description was changed from

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using 
ImageCapture types. 

This basically reproduces the media/cast and media/midi
structure. 

Windows import/export issues made necessary to add
capture_export and associated CAPTURE_EXPORT macro,
again, replicating media/midi. 


gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make 
them explicit (e.g. media:gpu).

BUG=518807
==========

to

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using 
ImageCapture types. 

This basically reproduces the media/cast and media/midi
structure. 

Windows import/export issues made necessary to add
capture_export and associated CAPTURE_EXPORT macro,
again, replicating media/midi. 


gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make 
them explicit (e.g. media:gpu).

BUG=518807
==========

[commit-bot: I haz the power, 2016-06-09 21:35:27]

Committed patchset #7 (id:580001)

[commit-bot: I haz the power, 2016-06-09 21:35:51]

CQ bit was unchecked

[commit-bot: I haz the power, 2016-06-09 21:38:28]

Description was changed from

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using 
ImageCapture types. 

This basically reproduces the media/cast and media/midi
structure. 

Windows import/export issues made necessary to add
capture_export and associated CAPTURE_EXPORT macro,
again, replicating media/midi. 


gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make 
them explicit (e.g. media:gpu).

BUG=518807
==========

to

==========
Make media/capture gn and gyps produce components
This CL separates media/capture into a component,
to allow, in a subsequent CL, linking with mojo for using
ImageCapture types.

This basically reproduces the media/cast and media/midi
structure.

Windows import/export issues made necessary to add
capture_export and associated CAPTURE_EXPORT macro,
again, replicating media/midi.

gn gen ... --check uncovered some transitive dependencies
during the "analyze" phase of the bots and I had to make
them explicit (e.g. media:gpu).

BUG=518807

Committed: https://crrev.com/f4683c359791bb0264cddddeca6b8bcae0e61817
Cr-Commit-Position: refs/heads/master@{#399024}
==========

[commit-bot: I haz the power, 2016-06-09 21:38:29]

Patchset 7 (id:??) landed as
https://crrev.com/f4683c359791bb0264cddddeca6b8bcae0e61817
Cr-Commit-Position: refs/heads/master@{#399024}

[mcasas, 2016-06-09 21:52:29]

A revert of this CL (patchset #7 id:580001) has been created in
https://codereview.chromium.org/2059493002/ by mcasas@chromium.org.

The reason for reverting is: Broke (at least)
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Builder%...:

FAILED: libmedia.dylib libmedia.dylib.TOC 
if [ ! -e "./libmedia.dylib" -o ! -e "./libmedia.dylib.TOC" ] || otool -l
"./libmedia.dylib" | grep -q LC_REEXPORT_DYLIB ; then
../../build/toolchain/mac/linker_driver.py /b/build/slave/cache/cipd/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared 
-Wl,-install_name,@rpath/"libmedia.dylib" -stdlib=libc++ -arch x86_64 -isysroot
/Applications/Xcode7.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-mmacosx-version-min=10.7 -Wl,-rpath,@loader_path/.
-Wl,-rpath,@loader_path/../../.. -o "./libmedia.dylib"
-Wl,-filelist,"./libmedia.dylib.rsp" -framework CoreVideo -framework
AVFoundation -framework AudioToolbox -framework AudioUnit -framework CoreAudio
./libshared_memory_support.dylib ./libffmpeg.dylib ./libbase.dylib
./libbase_i18n.dylib ./libcrcrypto.dylib ./libskia.dylib ./libevents_base.dylib
./libgfx.dylib ./libgeometry.dylib ./libgl_wrapper.dylib ./liburl.dylib
./libgpu.dylib ./libgles2_utils.dylib ./libicui18n.dylib ./libicuuc.dylib
./librange.dylib ./libui_base.dylib ./libplatform.dylib ./libgl_init.dylib
./libipc.dylib ./libboringssl.dylib && { otool -l "./libmedia.dylib" | grep
LC_ID_DYLIB -A 5; nm -gP "./libmedia.dylib" | cut -f1-2 -d' ' | grep -v U$$;
true; } > "./libmedia.dylib.TOC"; else
../../build/toolchain/mac/linker_driver.py /b/build/slave/cache/cipd/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared 
-Wl,-install_name,@rpath/"libmedia.dylib" -stdlib=libc++ -arch x86_64 -isysroot
/Applications/Xcode7.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-mmacosx-version-min=10.7 -Wl,-rpath,@loader_path/.
-Wl,-rpath,@loader_path/../../.. -o "./libmedia.dylib"
-Wl,-filelist,"./libmedia.dylib.rsp" -framework CoreVideo -framework
AVFoundation -framework AudioToolbox -framework AudioUnit -framework CoreAudio
./libshared_memory_support.dylib ./libffmpeg.dylib ./libbase.dylib
./libbase_i18n.dylib ./libcrcrypto.dylib ./libskia.dylib ./libevents_base.dylib
./libgfx.dylib ./libgeometry.dylib ./libgl_wrapper.dylib ./liburl.dylib
./libgpu.dylib ./libgles2_utils.dylib ./libicui18n.dylib ./libicuuc.dylib
./librange.dylib ./libui_base.dylib ./libplatform.dylib ./libgl_init.dylib
./libipc.dylib ./libboringssl.dylib && { otool -l "./libmedia.dylib" | grep
LC_ID_DYLIB -A 5; nm -gP "./libmedia.dylib" | cut -f1-2 -d' ' | grep -v U$$;
true; } > "./libmedia.dylib.tmp" && if ! cmp -s "./libmedia.dylib.tmp"
"./libmedia.dylib.TOC"; then mv "./libmedia.dylib.tmp" "./libmedia.dylib.TOC" ;
fi; fi
Undefined symbols for architecture x86_64:
  "_CFArrayCreate", referenced from:
      media::video_toolbox::ArrayWithIntegers(int const*, unsigned long) in
videotoolbox_helpers.o
      media::video_toolbox::ArrayWithIntegerAndFloat(int, float) in
videotoolbox_helpers.o
  "_CFDictionaryCreate", referenced from:
      media::video_toolbox::DictionaryWithKeysAndValues(void const**, void
const**, unsigned long) in videotoolbox_helpers.o
  "_CFGetTypeID", referenced from:
      media::VideoFrame::WrapCVPixelBuffer(__CVBuffer*, base::TimeDelta) in
video_frame.o
  "_CFNumberCreate", referenced from:
      media::video_toolbox::ArrayWithIntegers(int const*, unsigned long) in
videotoolbox_helpers.o
      media::video_toolbox::ArrayWithIntegerAndFloat(int, float) in
videotoolbox_helpers.o
      media::video_toolbox::SessionPropertySetter::Set(__CFString const*, int)
in videotoolbox_helpers.o
  "_CFRelease", referenced from:
      base::internal::ScopedCFTypeRefTraits<__CVBuffer*>::Release(__CVBuffer*)
in video_frame_mac.o
      media::video_toolbox::ArrayWithIntegers(int const*, unsigned long) in
videotoolbox_helpers.o
      media::video_toolbox::ArrayWithIntegerAndFloat(int, float) in
videotoolbox_helpers.o
      base::internal::ScopedCFTypeRefTraits<__CFArray const*>::Release(__CFArray
const*) in videotoolbox_helpers.o
     
base::internal::ScopedCFTypeRefTraits<OpaqueCMBlockBuffer*>::Release(OpaqueCMBlockBuffer*)
in videotoolbox_helpers.o
     
base::internal::ScopedCFTypeRefTraits<OpaqueVTCompressionSession*>::Release(OpaqueVTCompressionSession*)
in videotoolbox_helpers.o
      base::internal::ScopedCFTypeRefTraits<__CFNumber
const*>::Release(__CFNumber const*) in videotoolbox_helpers.o
      ...
  "_CFRetain", referenced from:
      base::internal::ScopedCFTypeRefTraits<__CVBuffer*>::Retain(__CVBuffer*) in
video_frame_mac.o
      base::internal::ScopedCFTypeRefTraits<__CFDictionary
const*>::Retain(__CFDictionary const*) in videotoolbox_helpers.o
      base::internal::ScopedCFTypeRefTraits<__CFArray const*>::Retain(__CFArray
const*) in videotoolbox_helpers.o
     
base::internal::ScopedCFTypeRefTraits<OpaqueCMBlockBuffer*>::Retain(OpaqueCMBlockBuffer*)
in videotoolbox_helpers.o
     
base::internal::ScopedCFTypeRefTraits<OpaqueVTCompressionSession*>::Retain(OpaqueVTCompressionSession*)
in videotoolbox_helpers.o
      base::internal::ScopedCFTypeRefTraits<__CFNumber
const*>::Retain(__CFNumber const*) in videotoolbox_helpers.o
      base::internal::ScopedCFTypeRefTraits<__CFString
const*>::Retain(__CFString const*) in audio_manager_mac.o
      ...
  "_CGEventSourceCounterForEventType", referenced from:
      media::(anonymous namespace)::UserInputMonitorMac::GetKeyPressCount()
const in user_input_monitor_mac.o
  "_OBJC_CLASS_$_NSBundle", referenced from:
      objc-class-ref in coremedia_glue.o
      objc-class-ref in videotoolbox_glue.o
      objc-class-ref in avfoundation_glue.o
  "_OBJC_CLASS_$_NSObject", referenced from:
      _OBJC_CLASS_$_AVCaptureDeviceGlue in avfoundation_glue.o
      _OBJC_CLASS_$_AVCaptureDeviceInputGlue in avfoundation_glue.o
  "_OBJC_CLASS_$_NSThread", referenced from:
      objc-class-ref in avfoundation_glue.o
  "_OBJC_METACLASS_$_NSObject", referenced from:
      _OBJC_METACLASS_$_AVCaptureDeviceGlue in avfoundation_glue.o
      _OBJC_METACLASS_$_AVCaptureDeviceInputGlue in avfoundation_glue.o
  "___CFConstantStringClassReference", referenced from:
      CFString in coremedia_glue.o
      CFString in videotoolbox_glue.o
      CFString in avfoundation_glue.o
      CFString in avfoundation_glue.o
      CFString in avfoundation_glue.o
      CFString in avfoundation_glue.o
      CFString in avfoundation_glue.o
      ...
  "__objc_empty_cache", referenced from:
      _OBJC_METACLASS_$_AVCaptureDeviceGlue in avfoundation_glue.o
      _OBJC_CLASS_$_AVCaptureDeviceGlue in avfoundation_glue.o
      _OBJC_METACLASS_$_AVCaptureDeviceInputGlue in avfoundation_glue.o
      _OBJC_CLASS_$_AVCaptureDeviceInputGlue in avfoundation_glue.o
  "__objc_empty_vtable", referenced from:
      _OBJC_METACLASS_$_AVCaptureDeviceGlue in avfoundation_glue.o
      _OBJC_CLASS_$_AVCaptureDeviceGlue in avfoundation_glue.o
      _OBJC_METACLASS_$_AVCaptureDeviceInputGlue in avfoundation_glue.o
      _OBJC_CLASS_$_AVCaptureDeviceInputGlue in avfoundation_glue.o
  "_kCFAllocatorDefault", referenced from:
      media::WrapVideoFrameInCVPixelBuffer(media::VideoFrame const&) in
video_frame_mac.o
      media::video_toolbox::DictionaryWithKeysAndValues(void const**, void
const**, unsigned long) in videotoolbox_helpers.o
      media::video_toolbox::ArrayWithIntegers(int const*, unsigned long) in
videotoolbox_helpers.o
      media::video_toolbox::ArrayWithIntegerAndFloat(int, float) in
videotoolbox_helpers.o
     
media::video_toolbox::CopySampleBufferToAnnexBBuffer(OpaqueCMSampleBuffer*,
media::video_toolbox::AnnexBBuffer*, bool) in videotoolbox_helpers.o
  "_kCFBooleanFalse", referenced from:
      media::video_toolbox::SessionPropertySetter::Set(__CFString const*, bool)
in videotoolbox_helpers.o
  "_kCFBooleanTrue", referenced from:
      media::video_toolbox::SessionPropertySetter::Set(__CFString const*, bool)
in videotoolbox_helpers.o
  "_kCFRunLoopCommonModes", referenced from:
      media::PCMQueueInAudioInputStream::Open() in audio_input_mac.o
  "_kCFTypeArrayCallBacks", referenced from:
      media::video_toolbox::ArrayWithIntegers(int const*, unsigned long) in
videotoolbox_helpers.o
      media::video_toolbox::ArrayWithIntegerAndFloat(int, float) in
videotoolbox_helpers.o
  "_kCFTypeDictionaryKeyCallBacks", referenced from:
      media::video_toolbox::DictionaryWithKeysAndValues(void const**, void
const**, unsigned long) in videotoolbox_helpers.o
  "_kCFTypeDictionaryValueCallBacks", referenced from:
      media::video_toolbox::DictionaryWithKeysAndValues(void const**, void
const**, unsigned long) in videotoolbox_helpers.o
  "_objc_msgSend", referenced from:
      (anonymous
namespace)::CoreMediaLibraryInternal::CoreMediaLibraryInternal() in
coremedia_glue.o
      VideoToolboxGlue::Loader::Loader() in videotoolbox_glue.o
      AVFoundationGlue::InitializeAVFoundation() in avfoundation_glue.o
      (anonymous namespace)::LoadAVFoundationInternal() in avfoundation_glue.o
      AVFoundationGlue::AVCaptureSessionClass() in avfoundation_glue.o
      AVFoundationGlue::AVCaptureVideoDataOutputClass() in avfoundation_glue.o
      +[AVCaptureDeviceGlue devices] in avfoundation_glue.o
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Traceback (most recent call last):
  File "../../build/toolchain/mac/linker_driver.py", line 186, in <module>
    Main(sys.argv)
  File "../../build/toolchain/mac/linker_driver.py", line 68, in Main
    subprocess.check_call(compiler_driver_args)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 540, in check_call
    raise CalledProcessError(retcode, cmd)
.