Pale Moon Linux GCC 6.3.0 so far so good

[Walter Dnes]

Gentoo Linux just recently upgraded stable GCC from 4.9.4 to 5.4.0, and moved 6.3.0 from "no keywords" to "unstable". I've been running 64-bit GCC 5.4.0 builds at home, on Gentoo linux, for some time, with no problems attributable to GCC 5.4.0. Today, I got a bit brave and built the master branch (27.4.0a1) with GCC 6.3.0, and it seems to run OK so far.

32-bit Linux Pale Moon could probably stay with GCC 4.9.4. A lot of 32-bit users are running older machines, with older distros. E.g. Puppy Linux runs "really old" libraries, but does have security fixes backported. I don't see the point of migrating 32-bit to 5.4.0 or 6.3.0, unless there are noticable speed-gains or resource-usage-reductions to be had, without breaking backwards compatability.

[khronosschoty]

Why have 32 bit and 64 bit target different compilers? Why spend the effort to target 6 series gcc; when 7 series is out?

[Walter Dnes]

Why have 32 bit and 64 bit target different compilers?

Many 32-bit Pale Moon users run older machines in 32-bit mode, for the simple reason that the machines were built before Intel started building 64-bit x86_64 CPUs, and do not have the 64-bit instruction set. These machines (single core pre-Nocona CPUs) simply do not have the power or RAM to run a "modern desktop". They end up using lightweight distros like Puppy Linux, that run older lighter system libs with backported security fixes http://murga-linux.com/puppy/viewtopic.php?t=90461

For various reasons, Pale Moon has to be built on CentOS6.5 to be backwards-compatable with these older libs. I use a 32-bit CentOS6.5 chroot on my 64-bit Gentoo desktop PC. CentOS6.5 comes with GCC 4.7.4. I manually built GCC 4.9.4 for the SSE-only contruibuted linux build. I've also built manually built GCC 5.4.0 in the chroot for personal unofficial builds on my ancient netbook, and a Lenovo T-400 laptop. I haven't tried building 6.3.0 under 4.7.4. It may work. But eventually, you'll get to a point where you can't build GCC version Y on GCC version X, where Y is significantly higher than X.

Why spend the effort to target 6 series gcc; when 7 series is out?

See "about:buildconfig" in Pale Moon, for the current compiler version number.

[Moonchild]

Changing a major compiler version is akin to touching every line of code.
Especially with a code base as massive as the Mozilla tree, changing compilers can (and almost inevitably will) cause at least a few issues. Often, those issues are distributed in cause between necessary code changes and compiler bugs.
Using a bleeding edge version of a compiler for stable, internet-connected software is risky. compiler bugs will not have been found or addressed for new major versions. 14 million lines of code may not happily compile on it, or produce unstable binaries. Instability and compiler bugs can put you at risk of remote code execution if you're talking about browser software.

[khronosschoty]

Fair enough. I was just thinking if the effort to move to new gcc version was going to be undertook, it might be wise to try and future proof that effort; as much as possible. I guess it depends on how quickly one is trying to make the transition.

[trava90]

Eventually we likely will begin using newer GCC, but not until we resolve the stability issues seen with newer GCC's in some cases (such as Steve Pusser's repo a while back and also some issues with private builds during the v27 beta period). As to when this happens I can't say because nobody is working on determining the cause of the instability with newer versions, and I don't have time to look into it right now with all the things happening in /dom/media/.