Both are new in 16 and both come from `libatomic` no longer being buildable
on its own without help.
`configure.ac` now refuses to run with an empty `CFLAGS`: it appends
`-fno-link-libatomic` and needs `AC_PROG_CC`'s conftests to see it, so it
will not let `AC_PROG_CC` supply the default instead.
configure: error: CFLAGS must be set.
The top level passes them down in a monorepo build; here each library is
configured on its own, so pass what `AC_PROG_CC` would have chosen anyway.
`Makefile.am` then grew an `all-local` hook copying `libatomic.la` into
`../../gcc/`, so a compiler built in the same object tree can link
`-latomic`. There is no such tree here -- the compiler is a finished package
and gets the library through its wrapper -- so the rule just fails:
install: cannot create regular file '/build/build/../../gcc/libatomic.so.1.2.0'
Drop the hook rather than the rule, to keep the difference from upstream
small.
Neither is caught by checking that patches apply: both are build failures on
a tree that patched cleanly.
Co-authored-by: Ben Siraphob <bensiraphob@gmail.com>
Assisted-by: Claude Code (Claude Opus 5)
Most of the patches here are cherry-picks of upstream commits, and eight of
them are in the `releases/gcc-16` branch. Applying them to 16 would simply
fail, so gate them on the version and split each list in two: the block that
is only for GCC 15, then the block that applies to both.
In `libatomic` that accounts for the whole list. Its second patch is the
hand-edit of the generated `aclocal.m4` that `fetchpatch` cannot carry for
the first, and 16 already includes `../config/gthr.m4` there.
The remainder of the driver series is trunk-only, so it stays unconditional,
as do the ones not upstream anywhere yet.
Assisted-by: Claude Code (Claude Opus 5)
A release tarball carries generated files that a git tree does not, and
two of those bit us.
`MD5SUMS` is generated when a tarball is rolled. Each sub-source
extractor asserted `[[ -f MD5SUMS ]]` before copying it, so every one of
them failed outright the moment `monorepoSrc` was a git tree:
unpacking source archive /nix/store/...-source
source root is source
<exit 1>
Copy it only when it is there.
The generated sources are the other half: a checkout lacks
`gengtype-lex.cc` and friends, which a tarball ships pre-built, so they
have to be regenerated. Take flex and bison as native inputs when
`fromVCS` says the source is a checkout.
Tarball builds are unaffected either way.
Assisted-by: Claude Code (Claude Opus 5)
A few patches of mine were just merged (yay!). Let's upgrade the
`fetchpatch` invocations from the original mailing list submission to
the accepted commit, accordingly.
I narrowed down the the files to patch because patching
autoconf-generated files will break, and is not needed because we are
regenerating those files anyways.
Because we're building things separately, we don't need the fancy
lib/... namespacing tricks that GCC normally does to squeeze itself in
the FHS. We can just use the normal autotools libdir and include dir,
and the nixpkgs infra will sort everything out.
Where possible I submitted patches to the mailing list, and fetched
those. The ones I am vendoring are the residuals which I don't think are
ready for upstreaming yet. (I can imagine a further reworking upstream
such that we wouldn't need our own patches of that sort, but it would be
good to get the first crop merged first before discussing that.)
