(Or you could use chromium's bundled clang.)

Ideally there would be a bundled version of gcc for people that still want to use it; I want to get us away from having to upgrade machine images where possible.

Of course, doing this at the last minute because something is broken isn't ideal, so I'm fine w/ upgrading the builders in this case.

Not sure what the name of this creek is, but I think we might be up it:

chrome-bot@vm59-m7:(Linux 14.04):~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"


chrome-bot@vm59-m7:(Linux 14.04):~$ dpkg --list | grep stdc++
ii  lib32stdc++-4.8-dev                   4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3 (development files)
ii  lib32stdc++6                          4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3 (32 bit Version)
ii  libsfstdc++-4.8-dev-armhf-cross       4.8.4-2ubuntu1~14.04.1cross0.11.2     all          GNU Standard C++ Library v3 (development files) (armhf)
ii  libsfstdc++6-armhf-cross              4.8.4-2ubuntu1~14.04.1cross0.11.2     all          GNU Standard C++ Library v3 (soft float ABI)
ii  libstdc++-4.8-dev:amd64               4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3 (development files)
ii  libstdc++-4.8-dev-armhf-cross         4.8.4-2ubuntu1~14.04.1cross0.11.2     all          GNU Standard C++ Library v3 (development files)
ii  libstdc++6:amd64                      4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3
ii  libstdc++6:i386                       4.8.4-2ubuntu1~14.04.3                i386         GNU Standard C++ Library v3
ii  libstdc++6-4.8-dbg:amd64              4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3 (debugging files)
ii  libstdc++6-armhf-cross                4.8.4-2ubuntu1~14.04.1cross0.11.2     all          GNU Standard C++ Library v3
ii  libx32stdc++-4.8-dev                  4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3 (development files)
ii  libx32stdc++6                         4.8.4-2ubuntu1~14.04.3                amd64        GNU Standard C++ Library v3 (x32)


chrome-bot@vm59-m7:(Linux 14.04):~$ sudo apt-get update -qq && echo Done
Done


chrome-bot@vm59-m7:(Linux 14.04):~$ dpkg --list | awk '/stdc++/ {print $2}' | xargs sudo apt-get install
Reading package lists... Done
Building dependency tree
Reading state information... Done
lib32stdc++-4.8-dev is already the newest version.
lib32stdc++6 is already the newest version.
libstdc++-4.8-dev is already the newest version.
libstdc++-4.8-dev set to manually installed.
libstdc++6 is already the newest version.
libstdc++6-4.8-dbg is already the newest version.
libx32stdc++-4.8-dev is already the newest version.
libx32stdc++6 is already the newest version.
libstdc++6:i386 is already the newest version.
libsfstdc++-4.8-dev-armhf-cross is already the newest version.
libsfstdc++6-armhf-cross is already the newest version.
libstdc++-4.8-dev-armhf-cross is already the newest version.
libstdc++6-armhf-cross is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 134 not upgraded.

Forgot to say earlier: Upgrading gcc also implies upgrading libstdc++, which has all kinds of consequences.

#3: what about gcc-4.9? I believe that's the version that adds -std=c++14

Looks like support came in gcc 5  (https://gcc.gnu.org/gcc-5/changes.html)

Looked at the -std flag in the gcc man page on a xenial based slave (gcc 5.4)

c++14
c++1y
        The 2014 ISO C++ standard plus amendments.  The name c++1y is deprecated.

On a trusty installation (gcc 4.8) 

c++1y
       The next revision of the ISO C++ standard, tentatively planned for 2017.  
       Support is highly experimental, and will almost certainly change in incompatible 
       ways in future releases.

Newer upstream versions of gcc for trusty can be picked up in this ppa. https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test.

So long trusty?

We definitely want to keep trusty around on the chromium bots. We've invested a lot of work into making our compiler and stdlib independent of the OS there, and chrome works fine on trusty still.

I don't know what webrtc wants to do with their bots.

If they just want their bots to work, I'd suggest they use chromium's clang. If they want to support a newer gcc, then they can either update the linux images, or download a prebuilt gcc (+libstdc++) and hook up their build to that. (If that's what you choose, I can help with some notes on how to do that; we used to do this on the bots that compile clang.)

But in the end this is up to the webrtc folks to decide.

We have a single bot that compiles with gcc. It's not officially supported, but if it's not hard, we'd prefer to fix it.

Downloading a prebuilt gcc (+libstdc++) sounds good. Please share the notes you have :)

1. Build gcc and upload it to somewhere on GCS:

contrib/download_prerequisites
mkdir build && cd build
../configure --prefix=$HOME/gcc485precise --enable-languages=c,c++ --disable-multilib --enable-checking=release
make -j24
make install-strip
cd ~
 ~/gsutil/gsutil cp -n -a public-read gcc485precise.tgz gs://your-bucket/your-dir/gcc485precise.tgz


2. In a runhook, download it from there

3. Copy the libstdc++.so from the package downloaded in 2 to the build dir, so that host binaries and built tests can find it

4. Add stuff to gn to enable full toolchain overrides, similar to what cros does (https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.chromiumos%2FChromiumOS_amd64-generic_Compile%2F37527%2F%2B%2Frecipes%2Fsteps%2Fgenerate_build_files%2F0%2Fstdout)

Sorry for hijacking a simple infra issue, but

The real worrisome thing here is that WebRTC is forced to drop support of Ubuntu 14.04, GCC (also putting libstdc++ in danger) and C++11 all at once, because of a decision we didn't make, and we're forced to do a hack to at least partially keep one of those things.

Chromium is "just" a desktop application and it's understandable how it can be free to move forward, but WebRTC, as a widely used library, can't just willy-nilly drop support for platforms that aren't even exactly outdated.

Well, that's because WebRTC chose to use Chromium's build files. We could also add a toggle so you can opt out of std=c++14 (probably the best short-term thing to do here), but maybe you're better off with your own build files.

(imho libraries with a C++ interface can only be statically linked, so all clients of webrtc could do something similar to chrome. See "Keeping up.." section on http://blog.llvm.org/2015/01/using-clang-for-chrome-production.html)

To avoid any confusion: neither Chromium nor Chrome is dropping support for Trusty, and we're going to be building on that platform for a long time to come.

However, there are only certain configs that we guarantee will work and we build them on the Chromium waterfalls accordingly. There are other configs (like GCC) that we feel free to break but will accept patches to fix.

As Nico said, if you don't want to tie yourselves to Chromium/Chrome's system requirements, then we need to figure out how to better isolate you.

The two obvious ways to do this are for you to depend on as little of Chromium's code as possible, and to make sure that your own builds are as hermetic as possible. 

In the meantime, it's bad that we apparently didn't communicate the upcoming changes to you far enough ahead of time (if at all) to ensure that you were warned. And, since we know that //build *is* shared by multiple projects, we need to make sure that we track as many of their requirements as possible.

It's not actually clear to me at the moment if there is anything broken other than the flags in //build ; Can WebRTC stay on an older version of //build for now until we can at least add a build flag to control whether or not to pass c++14? Or are there other dependencies that we need to pin? 

Thanks for your consideration.
I don't mean to throw blame here. I understand that it was WebRTC project's decision to directly depend on Chromium's build infrastructure and I don't have the knowledge to challenge it, even though it feels like things are slipping away.
Indeed, knowing that multiple projects depend on //build, maybe there should be some configurability at the cost of elegance of Chromium.

My personal opinion is that WebRTC does not need to move to C++14 yet, and yes, reverting to -std=c++11 should keep us green as before.
WebRTC is not currently broken per se, we're just unable to roll the build repository (so automatic roll is broken for all dependencies: https://codereview.webrtc.org/2990063002/diff/1/DEPS )

There is definitely already some configurability in //build and I am totally fine with adding more (within reason, of course). 

As Nico suggests in #c11, it sounds like for now we need to add a build flag. Does someone on the WebRTC tem want to take a stab at that CL, since it's probably easiest fothat whatever it is will work for you?

(removing the Infra>Labs component if we're not going to actually install stuff on machines at the moment).

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

commit 548607f5d6e65e27a7da3c173b90eff9224c8b7f
Author: Oleh Prypin <oprypin@chromium.org>
Date: Wed Aug 02 01:49:39 2017

Add an override to use C++11

This is used for projects that rely on Chromium's build infrastructure
after Chromium switched to C++14
https://chromium-review.googlesource.com/c/583635

Bug:  750683 
Change-Id: Id673a2474a1b5c606ce17b1ce8e7faa4de0cb5b9
Reviewed-on: https://chromium-review.googlesource.com/596870
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Oleh Prypin <oprypin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491195}
[modify] https://crrev.com/548607f5d6e65e27a7da3c173b90eff9224c8b7f/build/config/compiler/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/28104eb31b1ee531eac9e63e96a359f42834cd64

commit 28104eb31b1ee531eac9e63e96a359f42834cd64
Author: oprypin <oprypin@webrtc.org>
Date: Wed Aug 02 08:26:18 2017

Override C++ standard to -std=gnu++11

Chromium switched to C++14 but WebRTC does not want to follow suit.
This enables the override added in
https://chromium-review.googlesource.com/c/596870

BUG= chromium:750683 
NOTRY=True

Review-Url: https://codereview.webrtc.org/2992823002
Cr-Commit-Position: refs/heads/master@{#19207}

[modify] https://crrev.com/28104eb31b1ee531eac9e63e96a359f42834cd64/.gn

Since there's a workaround now, I'm lowering this to P-3.

libyuv is also affected
goobuntu has gcc 4.8.  is there a way to use an updated gcc?

Hi fbarchard@, we (WebRTC) did not pursue the path of getting an updated GCC. We just don't want to switch to C++14. Added an override for that, and the problem was gone.

https://bugs.chromium.org/p/chromium/issues/detail?id=750683#c9 has information if you want to try to get an updated GCC (I don't think these instructions were tested).

For the C++11 override see https://chromium-review.googlesource.com/596870 and https://webrtc.googlesource.com/src/+/370c6d5/.gn#44

FYI: PDFium wants to stay on C++11 for now as well, so we are setting use_cxx11 = true, just like WebRTC. https://pdfium-review.googlesource.com/14351

Ping for triaging.

I reckon this is fixed, no?