Decouple use_system_harfbuzz=1 from is_chromeos=1 & is_linux build flags

Decouple use_system_harfbuzz=1 from is_chromeos=1 & is_linux build flags

Instead, we should move to configuring the use_system_harfbuzz flag on
the Chromium OS build separately, see:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild#261

BUG=589342
R=dpranke,thakis

[drott, 2016-03-14 16:32:06]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-14 16:32:31]

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

[drott, 2016-03-14 16:35:57]

drott@chromium.org changed reviewers:
+ thakis@chromium.org

[drott, 2016-03-14 16:35:58]

I tried this on GN and on a quick pager render test it works fine even though
there are two copies of HarfBuzz, the system one that is pulled in via pango-ft,
and the statically linked version. I verified that the renderer uses the newer
version of HarfBuzz.

On GYP this fails however, due to linker warnings, as follows:
/usr/local/google/home/drott/dev/blink/src/third_party/binutils/Linux_x64/Release/bin/ld.gold:
warning: hidden symbol 'hb_font_destroy' in
obj/third_party/harfbuzz-ng/libharfbuzz-ng.a(obj/third_party/harfbuzz-ng/src/harfbuzz-ng.hb-font.o)
is referenced by DSO
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libpangoft2-1.0.so

What could we do about this? The Pango dependency is not yet removed, see
crbug.com/457307

[commit-bot: I haz the power, 2016-03-14 17:48:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-14 17:48:23]

Dry run: This issue passed the CQ dry run.

[Dirk Pranke, 2016-03-16 02:29:28]

On 2016/03/14 16:35:58, drott wrote:
> I tried this on GN and on a quick pager render test it works fine even though
> there are two copies of HarfBuzz, the system one that is pulled in via
pango-ft,
> and the statically linked version. I verified that the renderer uses the newer
> version of HarfBuzz.
> 
> On GYP this fails however, due to linker warnings, as follows:
>
/usr/local/google/home/drott/dev/blink/src/third_party/binutils/Linux_x64/Release/bin/ld.gold:
> warning: hidden symbol 'hb_font_destroy' in
>
obj/third_party/harfbuzz-ng/libharfbuzz-ng.a(obj/third_party/harfbuzz-ng/src/harfbuzz-ng.hb-font.o)
> is referenced by DSO
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libpangoft2-1.0.so
> 
> What could we do about this? The Pango dependency is not yet removed, see
> crbug.com/457307

If we have a dependency on the system/sysroot version of pango as well then this
change seems like a bad idea to me; who knows what sorts of issues might arise
from having two different copies of harfbuzz in the address space.

We have a similar issue with freetype when we link in a non-system version
(//third_party/freetype2) to content_shell, but in that case we explicitly build
as a shared library. That's okay because we don't actually ship the shared
library.

I don't think that shipping a custom harfbuzz.so is probably the right solution,
so we probably should just fix the CrOS sysroot issue instead.

I haven't had time to look into the sysroot issue the past few days, but if this
is urgent (or even if it isn't), I can try to look into it tomorrow.

[Nico, 2016-03-18 22:03:51]

On 2016/03/14 16:35:58, drott wrote:
> I tried this on GN and on a quick pager render test it works fine even though
> there are two copies of HarfBuzz, the system one that is pulled in via
pango-ft,
> and the statically linked version. I verified that the renderer uses the newer
> version of HarfBuzz.
> 
> On GYP this fails however, due to linker warnings, as follows:
>
/usr/local/google/home/drott/dev/blink/src/third_party/binutils/Linux_x64/Release/bin/ld.gold:
> warning: hidden symbol 'hb_font_destroy' in
>
obj/third_party/harfbuzz-ng/libharfbuzz-ng.a(obj/third_party/harfbuzz-ng/src/harfbuzz-ng.hb-font.o)
> is referenced by DSO
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libpangoft2-1.0.so

What I'm worried about is that nothing warns about this in a gn build. Do you
understand why? Does the warning appear in a gn build but it's not an error, or
does the warning not even show up? Do you know why?

[drott, 2016-03-22 08:49:13]

On 2016/03/18 at 22:03:51, thakis wrote:

> What I'm worried about is that nothing warns about this in a gn build. Do you
understand why? Does the warning appear in a gn build but it's not an error, or
does the warning not even show up? Do you know why?

It does not show up in GN. I don't know why that is.

[Dirk Pranke, 2016-04-02 03:11:18]

On 2016/03/22 08:49:13, drott wrote:
> On 2016/03/18 at 22:03:51, thakis wrote:
> 
> > What I'm worried about is that nothing warns about this in a gn build. Do
you
> understand why? Does the warning appear in a gn build but it's not an error,
or
> does the warning not even show up? Do you know why?
> 
> It does not show up in GN. I don't know why that is.

Okay, I think I've worked this all out now.

In GYP, when use_cairo=1 (which is the default on both desktop linux and
chromeos), //ui/gfx/gfx.gyp 
depends on //build/system/linux/system.gyp:pangocairo , which pulls in
pkg-config info for
pangocairo *and* pangoft2 . 

On desktop linux, pangoft2 is also pulled in via gtk2, which also pulls in the
system harfbuzz, so
everything is fine.

On chromeos=1, there's no gtk2, so we don't also pull in the system harfbuzz, so
pangoft2 
gets bent out of shape, generating the warnings.

In GN, for both desktop linux and chromeos=1, the logic is different and 
//build/system/linux:pangocairo does not pull in the pkg-config flags for
pangoft2, so we 
don't get the warnings (on desktop we still depend on gtk2 which will still pull
in pangoft2
that way, but it will also pull in the system harfbuzz in that case, so, no
warnings).

If you fix //build/linux/system.gyp to not pull in pangoft2's flags, things
appear fine.

So, barring running tests and seeing if anything weird happens, I think
statically
linking in harfbuzz-ng should be fine.

So, we should be able to decouple the flags.

I need to double-check all my logic on this on Monday, but I think this is the
path forward.