Follows the recipe's [source] move from same_as gcc13 to
path = "../gcc16/source". The old symlink pointed at
recipes/dev/gcc13/source and survived the recipe edit, which is why the
first GCC 16 build attempt was still compiling GCC 13 sources.
libiberty compiles getopt1.c against GCC's include/getopt.h, which
declares the GNU-internal _getopt_internal. relibc ships a getopt.h that
does not declare it and was shadowing GCC's:
getopt1.c:71: error: implicit declaration of function
'_getopt_internal'
Same shape as the cpuid.h shadowing already handled in recipes/dev/gcc13.
Verified: _getopt_internal errors 5 -> 0.
STILL FAILING, on a new and different phase: the HOST libstdc++ headers
are being pulled into the build --
/usr/include/c++/16/x86_64-pc-linux-gnu/bits/os_defines.h:44:
error: missing binary operator before token '('
which is __GLIBC_PREREQ evaluated where there is no glibc. That is a
host/target header leak, not a continuation of the getopt problem, and it
is unrelated to this commit's change.
Two corrections.
relibc dependency restored. Dropping gcc13 from gcc-native's deps also
removed what transitively staged relibc's headers, leaving the sysroot
with no libc headers at all -- no fenv.h, so libstdc++'s <cfenv> failed
with 'fenv_t has not been declared in ::'.
That corrects my earlier diagnosis: relibc's fenv.h is NOT a stub. It
delegates to openlibm_fenv.h, which dispatches on __x86_64__ to
openlibm_fenv_amd64.h where fenv_t and fexcept_t are both defined, and
relibc stages all of those headers. The header was simply never reaching
this recipe's sysroot. The previous commit message asserting a relibc
fenv gap was wrong.
relibc gitlink bumped for the fnmatch commit, which adds the GNU
FNM_FILE_NAME and FNM_LEADING_DIR that GCC 16's libiberty needs.
Repointed [source] from the gcc13 recipe to the Redox-ported GCC 16 tree
(local/recipes/dev/gcc16/source, upstream 16.1.0 + gcc-redox-port), which
is what produced the working cross toolchain in prefix/.
Building GCC 13 with the GCC 16 cross compiler was not a supported
configuration and each fix only revealed the next incompatibility -- a
C++11 pin for libcody, GCC 13's cpuid.h shadowing the toolchain's after
GCC 15/16 removed the withdrawn AVX512PF/ER/4VNNIW/4FMAPS and PREFETCHWT1
macros, and finally an ICE in gimple_build_eh_must_not_throw compiling
libsupc++. All three are gone on GCC 16: ICE 0, char8_t 0, cpuid 0.
Also fixed here:
- The stale same_as symlink (source -> recipes/dev/gcc13/source) survived
the recipe edit and kept feeding GCC 13 sources to the build. Removed.
- gcc13/gcc13.cxx dropped from dependencies: they build the compiler this
recipe no longer uses. The cross compiler comes from the prefix on PATH.
- Exempted from the tree-wide -std=gnu17 pin. That pin exists for the
C17-era recipes, but GCC 16's own sources are C23 and use `bool` as a
keyword: gcc/config/i386/i386.h:1722: unknown type name 'bool'.
- [package].version set explicitly -- same_as used to supply it, and a
path source leaves the cookbook nothing to infer from.
- Version-globbed the hardcoded 13.2.0 libgcc copy paths.
BLOCKED on a genuine relibc gap. libstdc++'s <cfenv> does
using ::fenv_t; using ::fexcept_t;
but relibc's fenv.h is a 3-line stub defining neither, so
libstdc++-v3/include/fenv.h fails. fenv.h is a C99/POSIX header owed
fenv_t, fexcept_t, the FE_* macros and the fe* functions. Implementing it
in the relibc fork is the fix -- per LOCAL-FORK-SUPREMACY-POLICY.md Rule 2
the fork must be complete -- and is real work, not a flag.
recipes/dev/gcc13 was claiming name='cxx' — conflicted with
local/recipes/dev/gcc-native also claiming 'cxx'. Renamed to match
directory names for unique package identification by the cookbook.
vasilito