In case you're not familiar with the current state of things, currently all of the other linux and android builds also build against checked-in sysroots by defaults on the box; the sysroots are downloaded via gclient runhooks, and so taking this route will not requires devs who want to use the 'chromeos=1' config to develop and test locally to do anything special like install things manually or use a chroot.

See also https://groups.google.com/a/chromium.org/d/topic/chromium-dev/GXz9qXYYlbo/discussion for some discussion on this including some other alternatives that were discussed.

Dirk, what happened to your first idea in the thread? 

-----Cut----here----------
One possible fix for this would be to decouple the two switches, so chromeos=1 would
not automatically imply using the system harfbuzz, and so using the linux64 sysroot
would still work fine; the side effect of this would be that in a real CrOS build (i.e., one
using cros_sdk etc.), you'd have to also set use_system_harfbuzz. This is presumably not
a problem, because the real CrOS builds already set a whole bunch of other variables
explicitly.
----cut---here-----------------

Nico liked it and that's also the first thing that came up in my mind when I saw  bug 589342 . (now I began to wonder why nobody (including me)  has tried it before...) 

BTW, a custom sysroot approach does have a benefit in that not just harfbuzz but also FreeType can be made current. Ubuntu's FreeType is also rather behind the upstream while CrOS has mostly up to date version of FreeType. 

There's a bug to link "our up-to-date copy" of FreeType statically to Linux Chrome (for security and features such as color font support and better CFF font support) as is the case for Android Chrome, but there's little move so far.

in comment #5 @jshin wrote:
> Dirk, what happened to your first idea in the thread? 

drott@ tried it, and it didn't work, but he didn't post that note to the main email thread. Quoting here, since it seems safe to do so:

> Hi Dirk, Nico,
> 
> after our discussion I made a CL for decoupling the switches: https://codereview.chromium.org/1801813002
> 
> Unfortunately, this build (chromeos=1), when using GYP does run into the problem that pango-ft pulls in
> system HarfBuzz and conflicts with the statically linked in version of HarfBuzz from 
> third-party/harfbuzz-ng. The build fails with linker warnings-as-error, more info in the CL.
>
> On GN this cros build and executable seems to work, I am not sure what are the differences 
> in the build configuration are which allow the linking step to go through. But a quick 
> rendering test shows that the new HarfBuzz version, i.e. the statically linked version 
> is used for rendering, despite the executable having libharfbuzz.so in lddtree 
> dependency tree via pango-ft as well.
>
> Dirk, if you have any suggestions on how we could solve these linker warnings, that'd be very helpful.

At which point I thought that this approach was going to be fairly dodgy and, given that I think the sysroot
approach is better overall, I told Dominic I didn't want to pursue it further.

As you say, adding sysroots may help w/ the custom freetype issue as well, although I think that one might
be a bit trickier since we actually want that in the official builds of desktop Linux as well (but it'll help
in the chromeos=1 case, for sure).

Dirk, thank you for the explanation. 
I have nothing but my poor memory to blame here. I think that a long time ago we had come across what drott@ came across recently (or at least similar in nature), which is why chromeos=1 and 'use_system_harfbuzz' are not decoupled. 

using a custom sysroot and then trying to execute the resulting program is problematic regardless of chromeos.  i guess it works w/linux because we use an older Debian sysroot, and we explicitly support only newer Ubuntu distros, so the compatibility *tends* to work out.

as for acquiring a general x86_64 sysroot, that's trivial to do today -- use `cros chrome-sdk --board=amd64-generic`.  the CrOS infra guarantees that stays current already.

> Using a custom sysroot and then trying to execute the resulting program
> is problematic regardless of chromeos.

Yes, however, I think it's still probably the best option for solving this problem.

> as for acquiring a general x86_64 sysroot ...

Yup, but as you expected, it turns out we can't actually execute these programs.

My current plan is to see if I can create a new sysroot that is a delta off of the wheezy sysroot but contains new enough harfbuzz (and other things that depend on harfbuzz) that we'll solve this problem. Unfortunately, I also don't know how scalable this solution will end up being.

if user namespaces were an option, then it would be possible to create & use a chroot on the fly, but i'm not sure that's enabled by default in the Debian/Ubuntu systems we use.  has the Chromium sandbox made that a hard requirement yet (in place of set*id) on linux in general ?  i know we were going to do it for CrOS since we guarantee sanity there kernel/system wise.

I think user namespaces are enabled and available on Trusty, at least (kernel 3.13), but not Precise  (kernel 3.2?):

https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md#User_namespaces_sandbox.md

So, maybe if we could migrate the chromeos=1 bots to Trusty this might be good enough, but I'm not sure what other changes would be need in the infrastructure to use chroots "on the fly", so I'd like to defer that if possible for now

i'm just throwing it out as a possible alternative idea.  i'm certainly not signing up to do any work at this time ;).

some distros (like Debian) have carried custom patches that disable userns by default.  see this article: https://lwn.net/Articles/673597/

Thanks for looking into this, Dirk. Any update on what you're suggesting in #10, the wheezy++ sysroot version?

I have been working on this off and on for the past few days.

In short, I think the wheezy++ sysroot approach is possibly harder than I thought
it would be, and now think decoupling the variables is perhaps the more preferable approach. I'm playing around with the latter now to look through the linker warnings you were hitting and double-checking my understanding; hopefully I'll have a better answer later today.

Sorry to add one more piece to the mix. I've just realized that pango on cros is rather old (3 years old. see bug 599596). Once it's updated to a recent version, pango may have to be in a sysroot, but Dirk just wrote that it's harder than expected to take that approach. 

Well, pango is not used by Blink. It's only for the "system UI" as opposed to web ui. 

Okay, I've done some more digging and added a comment to drott's CL linked above:

https://codereview.chromium.org/1801813002/#msg10

In short, I think decoupling the flags should work reasonably well for a developer config, assuming of course that all the tests pass. I would be nervous if we were shipping an official build this way, but IIUC the official CrOS builds have new enough libraries and so should be fine, it's just the unofficial developer chromeos=1/target_os="chromeos" builds that are too old (since we get the wheezy sysroot).

So, I think we can and should abandon this approach for the moment. It may be worth revisiting later when we have more time to play with running things out of a sysroot.

I will attempt to put together a double-checked version of drott's CL on monday and we can see if that'll land; if it does, then I suggest we WontFix this.

WontFixed, at least for now.

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

commit 17498ec3190acff0ae88d3083543a50da9d0af83
Author: thakis <thakis@chromium.org>
Date: Fri Mar 31 11:09:13 2017

Use new jessie sysroot for cros-desktop builds too.

BUG= 706006 , 598033 

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

[modify] https://crrev.com/17498ec3190acff0ae88d3083543a50da9d0af83/build/config/sysroot.gni