Three defects found and fixed, each verified to go to zero:
1. libcody C++ standard. Its configure contains
#if __cplusplus > 201103
#error "C++11 is required"
so anything newer than C++11 is rejected outright. My earlier
-std=gnu++17 tripped exactly this -- the 'C++11 is required' failure
came from build/libcody/config.log, not from a missing libstdc++ as
the previous commit assumed. C++11 also fixes the original problem:
char8_t arrived in C++20, so under C++11 u8"" is still const char[].
char8_t diagnostics: 100+ -> 0.
2. libcody is compiled by the CROSS compiler, not the host one --
x86_64-unknown-redox-g++ ... -c -o buffer.o .../libcody/buffer.cc
because --host is the Redox target. So plain CXXFLAGS is the right
knob, scoped to this branch; the freestanding branch must keep the
compiler defaults.
3. libgcc's cpuinfo.c needs CPUID bit macros from <cpuid.h>. Built by
GCC 16 that resolves to GCC 16's header, and GCC 15/16 REMOVED the
macros for the withdrawn AVX512PF/ER/4VNNIW/4FMAPS and PREFETCHWT1
extensions. GCC 13 ships its own cpuid.h that still defines them, so
its config dir now precedes the toolchain include path for target
compiles. Undeclared-bit errors: 5 -> 0.
BLOCKED, and not by a flag. GCC 16 now ICEs compiling GCC 13's own
libstdc++:
libstdc++-v3/libsupc++/eh_call.cc:39:1: internal compiler error:
in gimple_build_eh_must_not_throw
Each fix has revealed the next incompatibility; an ICE is where
flag-tweaking stops being the answer. Building GCC 13 with GCC 16 is
three major versions of drift and is not a supported configuration.
The coherent fix is to move gcc-native onto GCC 16, which is the whole
point of the port in local/patches/gcc-redox-port/ -- local/recipes/dev/
gcc16/source is already ported and is what produced the working cross
toolchain. That is an operator-level decision, so it is not taken here.
libcody is compiled by the CROSS compiler, not the host one -- the build
log shows
x86_64-unknown-redox-g++ ... -c -o buffer.o .../libcody/buffer.cc
because --host is the Redox target. So plain CXXFLAGS is the right knob,
not CXXFLAGS_FOR_BUILD as the previous commit assumed. Scoped to the
gcc-native branch only.
Verified: char8_t errors go 100+ -> 0.
STILL OPEN. With CXXFLAGS set, the top-level configure now fails its
build-side probe:
checking whether gcc accepts -g... no
configure: error: C++11 is required
The two states are exclusive as things stand:
- CXXFLAGS carrying -std=gnu++17 -> char8_t fixed, C++11 probe fails
- CXXFLAGS without it -> probe passes, char8_t fails
so something in the exported CXXFLAGS is unacceptable to the HOST gcc
that configure probes (the cookbook adds -fno-hardened -DHAVE_ALLOCA_H=1
-fPIC alongside a target -I). The recipe unsets CFLAGS/CPPFLAGS/LDFLAGS
for this branch but leaves CXXFLAGS set, which is the likely culprit --
the next step is to give the build-side compiler its own clean flags
rather than inheriting the target's.
Putting it in plain CXXFLAGS also handed it to the Redox cross g++, whose
C++ probe then failed during the freestanding stage, before libstdc++
exists:
configure: error: C++11 is required
libcody -- where the char8_t failures occur -- is compiled by
CXX_FOR_BUILD (the host g++ 16), so CXXFLAGS_FOR_BUILD is the correct
knob and the cross compiler is left alone.
gcc13
The host compiler is now GCC 16, which defaults to C++20
(__cplusplus 202002L). C++20 changed u8"" literals from const char[] to
const char8_t[], and GCC 13's libcody -- its module mapper -- uses them
throughout, so the build collapsed with ~100 diagnostics like
error: invalid conversion from 'const char8_t*' to 'const char*'
in libcody/{buffer,client,server}.cc. GCC 13's sources are C++17; build
them at that standard. Not a workaround -- it is the dialect this
release was written against.
rust / rust-native
nix 0.30.1 is incompatible with the resolved libc 0.2.178: it declares
type SaFlags_t = libc::c_ulong while libc now has sigaction.sa_flags and
the SA_* constants as c_int, so rustc's bootstrap tooling failed with
error[E0308]: expected `u64`, found `i32` nix/src/macros.rs:72
error[E0308]: expected `i32`, found `u64` nix/src/sys/signal.rs:808
nix 0.31 fixed it by flipping the default to c_int. ctrlc moves itself
(3.5 requires nix "0.31"), but in-tree miri pinned 0.30.1 and kept the
broken version in the graph, so both are moved forward -- update and
adapt rather than pinning libc back, per the
Most-recent-upstream-when-building rule. Both crates were already in the
offline registry cache.
These surfaced only because gcc-native/rust-native were restored to the
config; neither had been building.
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.
Derivative of Redox OS (https://www.redox-os.org) adding:
- AMD GPU driver (amdgpu) via LinuxKPI compat layer
- ext4 filesystem support (ext4d scheme daemon)
- ACPI fixes for AMD bare metal (x2APIC, DMAR, IVRS, MCFG)
- Custom branding (hostname, os-release, boot identity)
Build system is full upstream Redox with RBOS overlay in local/.
Patches for kernel, base, and relibc are symlinked from local/patches/
and protected from make clean/distclean. Custom recipes live in
local/recipes/ with symlinks into the recipes/ search path.
Build: make all CONFIG_NAME=redbear-full
Sync: ./local/scripts/sync-upstream.sh
vasilito