4 ms·

This decision came from the GCC Steering Committee, which has nothing to do with the FSF. The history of GCC includes a dark period in which version control wa

This decision came from the GCC Steering Committee, which has nothing to do with the FSF. The history of GCC includes a dark period in which version control wasn't public, and the project was dumping release tarballs on the GNU ftp server. Then, Cygnus Solutions started the Experimental GNU Compiler Suite (EGCS), a fork with a much more open development model, capable of attracting contributions from the whole Linux and embedded industry. Within a few years, many Linux distros had switched to EGCS, including Red Hat. If I remember correctly, talks of reconciliation started after Red Hat acquired Cygnus: other distros were worried that their competitor had gained too much control over a critical component of the OS. Eventually, the GNU developers and the EGCS contributors agreed to merge back under the GNU flag, but keeping EGCS's open development model. Nowadays, the GCC project is still hosted on the Red Hat-owned Sourceware servers, and its governance body is a technical board of contributors with various industry affiliations: https://gcc.gnu.org/steering.html https://gcc.gnu.org/steering.html TL;DR: the FSF and the GNU project no longer have much influence on GCC's direction.

not2b 5y ago
Not that simple: EGCS was deliberately structured so that Cygnus would not control it; it involved many GCC developers who didn't work for them. The original EGCS steering committee had a non-Cygnus majority. From the very beginning, it was structured in such a way that it could become the official GCC once reality set in. This had nothing to do with Cygnus being acquired. There wasn't a working Linux libstdc++ from the FSF that anyone could build until EGCS fixed it; no Linux distros that supported C++ ever used an FSF version. They had to use weird hacks built by HJ Lu.
- sitkack 5y ago
  I have vague memories of this time period. It seemed like GCC had stagnated and development wasn't being done in public. Many of the same gripes about extensibility and velocity that spawned the creation of clang/llvm. please no license fights.
  - not2b 5y ago
    The fight that led to EGCS had nothing to do with licensing. It had to do with a broken development process that the release manager wasn't willing to change. About two years of backlogged bugfixes for C++ were in some state of acceptance, but things were such a mess that releases weren't really possible: people got email saying that the bug would be fixed in the next major release of g++ but it never happened. EGCS kept the same licensing policies and also kept copyright assignment in place. Some developers wanted a clean break with the FSF, but most just wanted to get GCC fixed. It was a delicate dance to keep RMS from getting pissed off and trying to shut it down; one selling point that kept him calmer was that doing it the EGCS way kept Cygnus from just owning everything and taking over.
    - lanstin 5y ago
      2.7.2 the current for a while then you could manually update to some iffy 2.9.5 release? I never did much c++ in the 90s. 2.7.x was generally fine for c on hpux/Solaris/digital/Linux and maybe os/x?
    - sitkack 5y ago
      I made no statements about licensing. It was all about updates and developer velocity. Lots of folks wanted to get patches into GCC and the GCC devs at the time were camping on the submission queue. The EGCS fork was a way around that, but a balkanized compiler is kinda like a poison pill, as soon as someone uses a feature in one and not the other, it bifurcates a codebase. Think of what would have happened if some distros took alternate tooling paths? What about popular tools? We have to have both toolchains on our systems. It is clear from how things turned out that EGCS wasn't about ownership or splitting the ecosystem. If one were to do this now, you would constantly rebase against upstream while you sort out the politics. Clang/LLVM was both about implementation architecture and licensing, but had GCC been more modular, it might not have existed as well.

not2b 5y ago

Not that simple: EGCS was deliberately structured so that Cygnus would not control it; it involved many GCC developers who didn't work for them. The original EGCS steering committee had a non-Cygnus majority. From the very beginning, it was structured in such a way that it could become the official GCC once reality set in. This had nothing to do with Cygnus being acquired. There wasn't a working Linux libstdc++ from the FSF that anyone could build until EGCS fixed it; no Linux distros that supported C++ ever used an FSF version. They had to use weird hacks built by HJ Lu.

sitkack 5y ago
I have vague memories of this time period. It seemed like GCC had stagnated and development wasn't being done in public. Many of the same gripes about extensibility and velocity that spawned the creation of clang/llvm. please no license fights.
- not2b 5y ago
  The fight that led to EGCS had nothing to do with licensing. It had to do with a broken development process that the release manager wasn't willing to change. About two years of backlogged bugfixes for C++ were in some state of acceptance, but things were such a mess that releases weren't really possible: people got email saying that the bug would be fixed in the next major release of g++ but it never happened. EGCS kept the same licensing policies and also kept copyright assignment in place. Some developers wanted a clean break with the FSF, but most just wanted to get GCC fixed. It was a delicate dance to keep RMS from getting pissed off and trying to shut it down; one selling point that kept him calmer was that doing it the EGCS way kept Cygnus from just owning everything and taking over.
  - lanstin 5y ago
    2.7.2 the current for a while then you could manually update to some iffy 2.9.5 release? I never did much c++ in the 90s. 2.7.x was generally fine for c on hpux/Solaris/digital/Linux and maybe os/x?
  - sitkack 5y ago
    I made no statements about licensing. It was all about updates and developer velocity. Lots of folks wanted to get patches into GCC and the GCC devs at the time were camping on the submission queue. The EGCS fork was a way around that, but a balkanized compiler is kinda like a poison pill, as soon as someone uses a feature in one and not the other, it bifurcates a codebase. Think of what would have happened if some distros took alternate tooling paths? What about popular tools? We have to have both toolchains on our systems. It is clear from how things turned out that EGCS wasn't about ownership or splitting the ecosystem. If one were to do this now, you would constantly rebase against upstream while you sort out the politics. Clang/LLVM was both about implementation architecture and licensing, but had GCC been more modular, it might not have existed as well.