New issue
Advanced search Search tips

Issue 227320 link

Starred by 123 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature

  • Only users with EditIssue permission may comment.

Sign in to add a comment

support for RHEL/CentOS/SL 6 for version 28+

Reported by, Apr 6 2013

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

Steps to reproduce the problem:
EOL after version 26 for RHEL/CentOS/SL 6 using gcc 4.4

What is the expected behavior?
Continued support using gcc 4.7.2 and toolchain provided by

What went wrong?
I'm assuming chromium devs want gcc that supports better C++11 standard.

Did this work before? N/A 

Chrome version: 26.0.1410.43  Channel: stable
OS Version: CentOS 6.4 x86_64

Please let us know if there are any other dependencies required that the RHEL/CentOS/SL communities may be able to supply.
Mergedinto: 224389
Status: Duplicate

Comment 2 by, Apr 11 2013

Status: Untriaged
This is not a dupe, as @thestig specifically asked for a separate issue to be submitted for CentOS.

Question is: what is Chromium's support for CentOS, if any?
I don't see how the Red Hat Developer Toolset helps. It's a tool set to let developers use gcc 4.7 to build programs that run on RHEL. It doesn't provide any shared libraries that let programs build on another system (with different expectations for the shared libraries) run on RHEL 6.

The Developer Toolset may help someone build a copy of Chromium for RHEL 6, but it won't make future Google Chrome releases run on RHEL 6.

To help get my point across, take the attached sample foo.c, build it on an Ubuntu 12.04 machine with gcc -O0 foo.c, and try to run it on RHEL 6. It won't work because nothing on RHEL 6 provides the GLIBC_2.14 versioned symbols. Similarly, nothing provides the GLIBCXX_3.4.15 versioned symbols needed for Chrome or the Chromium continuous builds.
224 bytes View Download

Comment 4 by, May 2 2013

I'm pretty versed in both cross-compiling and setting up environments that include bundled libraries for the purpose of using newer API-using code on older OS's.

It should be possible to set up a build environment (with either .so's that end up bundled with the binary, or static PIC .a libraries for the newer GTK) in a chroot or similar. Such an environment should provide a build that will work just fine on F12/EL6 or later, by virtue of the newer extras being bundled with the binaries.

It doesn't necessarily need the RH Developer Toolset; this could just as easily be done with a hand-built gcc, so long as it points at an EL6 set of include/lib files as its basis, and the extras built out-of-band and added to the include/lib path.

Comment 5 by, May 2 2013

[In case that wasn't clear, I'm volunteering to help if any advice is desired. You can feel free to contact me directly.]
I believe that the Developer Toolset is designed to take care of the library/linking issue for deployment on existing systems. My understanding is that they reuse existing libraries as much as possible and then when a newer library is needed it's statically linked.

See slide 12 from
re: comment 5 - if you are volunteering to help, please try to achieve the following:

Start with a Ubuntu 12.04 machine, build a Chromium binary that's comparable in size (sans debugging symbols) to a Chromium binary built with the the native toolchain. Make sure the binary run on RHEL 6, Fedora 17, OpenSUSE 12.2, Debian 7, and Ubuntu 12.04.

Comment 8 by, May 8 2013

Ah, that finally gives a reasonable explanation behind the requirement for newer libraries: moving the [dev and] build systems from 10.04 to 12.04, and producing both .rpm and .deb packages from the same systems. Not precisely the "we want newer libraries and/or C++11 features" rationale expounded elsewhere, but this time it's a lot more believable.

It may still be possible, so will give it a whirl. First the actual build, then the layout tests. Probably start by doing this with a 10.04 (lucid) chroot + updated toolchain, which would be ABI-compatible with all the requirements listed in #7.* For automated build systems, this would be cleaner than a gcc "Canadian-cross-to-self" configuration.

(* modulo needing a copy of and for older systems, though this would not be required for the newly announced set of "supported" systems, which have a gcc 4.6 or later runtime preinstalled.)
Developers still want newer libraries and C++11 features, but for this bug report, I'm raising the toolchain issue.
Cc:!forum/chromium-packagers may be a more appropriate place for discussions.

Short story is that our current official build infrastructure is very Ubuntu-centric. I'm not saying it's perfect, but for better or worse it won't change soon (definitely not weeks).

My recommendations for anyone interested in the browser on systems not officially supported by Google Chrome is to package Chromium instead. I'd be happy to help people with that - preferably through the above mailing list. :)

Comment 11 by, May 22 2013

I've opened a bug with the RHEL team, and it seems to have active involvement from RedHat.  They've proposed many possible solutions, some of which are build options, and many of which may provide paths forward for the Chromium team.

Is anybody interested in checking in with RedHat to see how this can be accomplished?

The Bug is here (requires account):

Comment 12 by Deleted ...@, Jun 19 2013

[root@localhost etc]# sudo yum install googlr-chrome
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * base:
 * extras:
 * updates: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
Trying other mirror.
Setting up Install Process
No package googlr-chrome available.
Error: Nothing to do

A best practice in building for Linux distributions is to build different packages for different targets, e.g. a different RHEL5, RHEL6, Fedora18, Ubuntu 10.04 or Ubuntu 12.04 package. Trying to make single package to target multiple distributions is ugly at best. And it is surprising it worked for Chome for this long. Sheer luck (or maybe Ubuntu surfing on RHEL's compatibility tail ?)

That said, there's a lot of information already available on how to build packages on native systems (either using chroots or virtual machines). Am willing to help wrt. RHEL/CentOS/SL.

BTW What distributions are officially supported by Google Chrome ? I have never seen such a statement.
BTW2 Despite the bugreport, v27 worked fine on my RHEL6.4 system, it's v28 that is causing havoc :-/

Comment 14 by, Jun 19 2013

Officially supported platforms for Linux distribution have always been stated on Chrome's download page (and specifically for Linux):

For Linux (Debian/Ubuntu/Fedora/openSUSE)

And specifically, since June 17, 2013, the Linux requirements for Chrome have been updated:

The Stable channel has been updated to 28.0.1500.45 for Linux.

The minimum requirements for Linux have also been updated:

Ubuntu 12.04+
Debian 7+
OpenSuSE 12.2+
Fedora Linux 17+

Dag, feel free to take a look at src/chrome/installer/linux for scripts used to create the Chrome package ( .

While I can't guarantee acceptance of any patch, feel free to experiment with the sysroot scripts to make it work on more systems (note that it's important to have C++11 support).

Also note that any distribution is free to use publicly available Chromium sources to create a package.

Comment 16 by, Jun 23 2013

I was also informed of this other page for all officially supported platforms and requirements for Chrome:

 Issue 252883  has been merged into this issue.
Summary: support for RHEL/CentOS/SL 6 for version 28+ (was: support for RHEL/CentOS/SL 6 for version 27+)
 Issue 252883  has been merged into this issue.

Comment 20 by Deleted ...@, Jul 1 2013

I guess the solution if firefox - oh hum

Comment 21 by, Jul 1 2013

Since the demand was thus:

"Start with a Ubuntu 12.04 machine, build a Chromium binary that's comparable in size (sans debugging symbols) to a Chromium binary built with the the native toolchain. Make sure the binary run on RHEL 6, Fedora 17, OpenSUSE 12.2, Debian 7, and Ubuntu 12.04."

I'm punting. As comment #13 describes, builds intended to support many releases generally result in multiple packages -- and older systems often require larger resultant packages (to bundle in newer dependencies than those offered by the OS itself).

Sure, I was able to build against a system with an upgraded g++ compiler, newer libstdc++, and can easily update other libraries and bundle them with the result -- but that *necessarily* means a larger, not comparably-sized result.

<shrug> This is the kind of attitude that will hurt in the long run.
sysroot-scripts are the key. Debian 7 already builds from a sysroot. All the pieces are there, the support for RHEL just needs to be added.

If "mock" were still a ubuntu package (it was in lucid but not precise), then it might have been just a few lines script to create an SRPM and pass it to mock. But since it is no longer a package, something a bit more complex is needed.

Here is the mock homepage for reference:
Sorry, double-paste there. The correct link is

Comment 24 by, Jul 13 2013

Just a note that I completed a script today that actually gets Chrome 28 working on CentOS 6. It involves downloading some Fedora 15 RPMs and copying them into /opt/google/chrome/lib (with a mod to the copied along the way).

I've created a quick one page site for the script at - hopefully folks here can try it out. It needs to be run as root and does a fair number of downloads/installs. It also hasn't been tested at all on 32-bit CentOS I'm afraid - just on 64-bit CentOS 6.4 so far.

Comment 25 by, Jul 13 2013

Why is it that we need to start hacking away and messing with installs just to get the browser installed ? I really don't get it.. 

Why not a proper fix from upstream - whoever that may be, Google for allowing earlier glibc versions, or CentOS/Redhat guys for upgrading their glibc... ?

Comment 26 by, Jul 13 2013

Red Hat (and its derivative distros) won't be updating glibc in a given release version, because the whole point of the distro is long-term stability (measured in multiple years).

Comment 27 by, Jul 13 2013

My script is really just a temporary holdover until RHEL/CentOS 7 comes out, hopefully later this year. It should be noted that Mozilla were equally naughty with Firefox 4 and RHEL/CentOS 5 - see - but the similar workaround for that was a single shared library (and RHEL/CentOS 6's release too of course).

The disappointing aspect here is that Google doesn't seem to care about supported long term releases of Linux installations, especially since "rivals" like Firefox and Opera work perfectly on them . I guess it's not unsurprising when you realise that "64-bit" Linux Google Earth shipped with only 32-bit libraries and binaries for a couple of years - sloppy or what?!
and even if CentOS 7 is released ... it will be to unstable to use, and i don't know who will upgrade an entire OS just for a freakin` browser ...

i intend to use CentOS 6 until End of Life ...
firefox works fine for me
Would someone mind posting the install script from ? That site is filtered by the corporate proxy at my office for some reason.
not sure if i'm allowed to .. but i will post it anyway
i hope Richard Lloyd won't mind :)

script i attached to this comment is at version 2 ( 14 july version )
16.2 KB View Download

Comment 32 by, Jul 17 2013

Worked like a charm. Thanks team. 

Now hoping for this to be fixed the `right` way soon :)
Thanks for posting Version 2 of the script. It worked for me. I had to blow
away ~/.config/google-chrome and resync my browser settings from my Google
account to get things to work properly, but this is a pretty normal for me
for any Chrome upgrades so probably does not reflect any issues with the script.

In case it helps, this is the size of final installation generated by

$ du -hcs /opt/google/chrome/
166M /opt/google/chrome/

Comment 34 by, Jul 19 2013

Just a note that version 2.10 of is available, but it's mainly a maintenance release and unfortunately there are two outstanding issues I still need to try to fix. One is the clash of the F15 libraries with CentOS 6 system libs when Chrome tries to load/run any external binaries or plug-in libraries (which tend to crash :-( ). The other is to create an RPM containing the F15 libs and a libstdc++ dependency resolution to keep yum/rpm quiet.

Note that running the 2.00 script that was attached earlier will prompt for an upgrade to 2.10, but if you're proxy-blocked then that isn't going to work...
new version

3.11 ( 25th July 2013 - set SELinux context types for F15 libraries/dir, warn if SELinux enabled and enforcing )

 This is a bash script, so after downloading it, you run it as root:

chmod u+x

In order for nacl_helper to start correctly, the current release requires you to disable SELinux e.g. temporarily with "echo 0 >/selinux/enforce" as root or permanently by editing /etc/selinux/config to set SELINUX=permissive and then rebooting. A future release will hopefully set some SELinux policies to avoid this requirement.

The script has optional command line arguments - here's the output of "./ -h":

Syntax: ./ [-d] [-h] [-n] [-q] [-u]
-d (or --delete) will delete the temporary directory used for downloads
   if an installation was successful.
-h (or -? or --help) will display this syntax message.
-n (or --dryrun) will show what actions the script will take,
   but it won't actually perform those actions.
-q (or --quiet) will switch to "quiet mode" where minimal info is displayed.
   Specify -q twice to go completely silent except for errors.
-u performs an uninstallation of Google Chrome rather the default
   action of an installation.
36.1 KB View Download

Comment 36 by, Jul 26 2013

WARNING:  workaround script above will break RHEL6.

I was decommissioning a RHEL6 box anyway and tried this script.  I don't know what piece called it, but basic commands like "grep" and "awk" started failing.  I suspect it replaced a core shared library somewhere with an incompatible version.  I didn't look long for a root cause because I was going to install Fedora 19 on that laptop anyway.
Labels: Restrict-AddIssueComment-EditIssue
Sorry, this is not a forum for third party scripts.

I understand the issue here, and I'm willing to work with packagers of any distro to produce a working Chromium package for given distro.
Status: Available
Status: WontFix
We have no plans to provide support for those platforms at this time.

Sign in to add a comment