Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline

Warner Losh imp at bsdimp.com
Tue Aug 13 16:00:44 UTC 2019


Greetings,

As promised for almost the past decade or so, gcc 4.2.1 will be removed
from the tree before FreeBSD 13 is branched.

I propose the following timeline for its removal:

2019-08-31: disconnect gcc 4.2.1 from CI build

Turn off -Werror on gcc 4.2.1 platforms

Turn off all gcc 4.2.1 from universe by default (can be turned on)

2019-12-31: Turn off gcc 4.2.1 build by default (can be turned on)

2020-03-31: svn rm gcc 4.2.1 and friends

2020-05-31: svn rm all non-clang platforms not supported by in-tree LLVM or
converted to ext toolchain.

2020-07-31: svn rm all ext toolchain platforms not supported by re@ release
scripts

The basic notion is that it’s long past time to have a firm plan for EOL
gcc 4.2.1 in the tree. There is ample external toolchain support today for
platforms that need it to build images, though that integration with
buildworld could use some more polish. It’s now completely sufficient to
move to the next phase of removing gcc 4.2.1 from the tree.

We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should
somewhat mitigate the risk for cross-compiler portability. This is a
long-established part of our CI. We want to retain gcc support for modern
versions of gcc since its debuggability is higher. Notifications for this
are currently turned off, but will be enabled soon. It’s expected that this
always will be working later in the year. We’ll work to update the
committers guide to reflect this, as well as give a recipe for testing.

The first phase will be at the end of the month. We’ll turn off -Werror on
gcc 4.2.1 (and MFC it to stable/11 and stable/12). We’ll then stop building
all platforms that require it as part of CI. New warnings will come up, but
will no longer waste developer time in trying to fix. Gcc 4.2.1 platforms
will no longer be built as part of universe, unless you add
-DMAKE_OBSOLETE_GCC is added to the command line. We plan on implementing
this by 2019-08-31.

An experimental branch will be created that will remove gcc related bits to
expose gaps in planning and to come up with a list of action items needed
to ensure Tier 1 platforms are unaffected by the gcc removal. The timeline
for this is by the end of September.

Next, we’ll turn off building gcc by default. This will effectively break
all gcc platforms with in-tree compilers. The external toolchain support we
have will suffice here, and patches will be accepted for whatever
integration are needed for these platforms with our current ports /
packages. The onus for these changes will be squarely on people that want
the platforms to continue. However, as a stop-gap gcc building can be
turned on for those people transitioning gcc-only platforms until gcc 4.2.1
is removed. This will happen on or about 2019-12-31.

After a 3 month transition period, gcc 4.2.1 will be removed from the tree.
This will be done on or about 2020-03-31.

After an additional 2 month transition period, all those platforms that
have not integrated with the FreeBSD CI system, work in a make universe
with the proper packages installed, and are shown to boot on real hardware
will be removed from the tree. This will happen on or about 2020-05-31.

After an additional 2 month grace period, those platforms that require
external toolchain integration that aren’t supported by the release
engineer’s release scripts will be removed. This  will happen on or about
2020-07-31.

The timeline gives powerpc, mips, mips64, and sparc64 9 months to integrate
either into an in-tree compiler, or to have a proven external toolchain
solution. This is on top of the many-years-long warnings about this being
the end game of the clang integration.

This is the proposed timeline, but should there be a significant issue
that’s discovered, the timeline can be amended.

Also note: the all toolchains in tree discussions are specifically out of
bounds here. Let’s remove one compiler and get the infrastructure needed to
make external toolchains robust before embarking on that discussion.

Comments?

Warner


More information about the freebsd-arch mailing list