Fix wrong libexif target type in GN build.

linux/win: Fix wrong libexif target type in GN build.

ExifFunctions in image_metadata_extractor.cc loads libexif as
a dll/so, so the target needs to be a shared_library.

This isn't quite right on OS X yet, but it fixes the problem on other
platforms at least.

Committed: https://crrev.com/23a031851c5a181a8e1bf0f4bec4124ff45bb446
Cr-Commit-Position: refs/heads/master@{#348697}

[Slava Chigrin, 2015-09-11 22:22:37]

vchigrin@yandex-team.ru changed reviewers:
+ thakis@chromium.org

[Slava Chigrin, 2015-09-11 22:23:52]

This is fix of the problem from 
https://codereview.chromium.org/809343008/

Sorry for so long reaction - I was very busy this week....

[Nico, 2015-09-11 22:33:23]

Thanks! Have you verified that e.g. ImageMetadataExtractorTest.JPGFile passes
with this?
(http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29%20tes...)

[Slava Chigrin, 2015-09-14 13:59:32]

On 2015/09/11 22:33:23, Nico wrote:
> Thanks! Have you verified that e.g. ImageMetadataExtractorTest.JPGFile passes
> with this?
>
(http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29%20tes...)

Yes, just checked locally - this patch indeed fixes this test in GN build.

[Nico, 2015-09-14 18:12:16]

On 2015/09/14 13:59:32, Slava Chigrin wrote:
> On 2015/09/11 22:33:23, Nico wrote:
> > Thanks! Have you verified that e.g. ImageMetadataExtractorTest.JPGFile
passes
> > with this?
> >
>
(http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29%20tes...)
> 
> Yes, just checked locally - this patch indeed fixes this test in GN build.

Lgtm. Maybe expand the cl description to say _why_ this change is made  (tests
try to load this as dll).

[Nico, 2015-09-14 19:33:47]

On 2015/09/14 18:12:16, Nico wrote:
> On 2015/09/14 13:59:32, Slava Chigrin wrote:
> > On 2015/09/11 22:33:23, Nico wrote:
> > > Thanks! Have you verified that e.g. ImageMetadataExtractorTest.JPGFile
> passes
> > > with this?
> > >
> >
>
(http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64%28dbg%29%20tes...)
> > 
> > Yes, just checked locally - this patch indeed fixes this test in GN build.
> 
> Lgtm. Maybe expand the cl description to say _why_ this change is made  (tests
> try to load this as dll).

Actually, let me do this myself and hit cq for you :-)

[Nico, 2015-09-14 19:37:33]

https://codereview.chromium.org/1343453002/diff/1/third_party/libexif/BUILD.gn
File third_party/libexif/BUILD.gn (right):

https://codereview.chromium.org/1343453002/diff/1/third_party/libexif/BUILD.g...
third_party/libexif/BUILD.gn:22: shared_library("libexif") {
(FWIW, this is probably not correct on OS X yet. shared_library becomes a
.dylib, while the code tries to load a .so. You can set output_extension to
override this; also this should probably be a loadable_module; but that's not
implemented yet: https://code.google.com/p/chromium/issues/detail?id=380327)

[Nico, 2015-09-14 19:37:36]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-09-14 19:37:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1343453002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1343453002/1

[commit-bot: I haz the power, 2015-09-14 20:10:53]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-09-14 20:11:41]

Patchset 1 (id:??) landed as
https://crrev.com/23a031851c5a181a8e1bf0f4bec4124ff45bb446
Cr-Commit-Position: refs/heads/master@{#348697}

[commit-bot: I haz the power, 2015-09-23 12:36:23]

Patchset 1 (id:??) landed as
https://crrev.com/23a031851c5a181a8e1bf0f4bec4124ff45bb446
Cr-Commit-Position: refs/heads/master@{#348697}