vasilito
0a6f11b719
redbear-ci / check (push) Has been cancelled
Three defects. gcc-native now cooks and publishes both packages.
1. Generator links failed with `undefined reference to __letf2@GCC_4.3.0`
(+ __gttf2 __eqtf2 __getf2 __unordtf2). The Redox libgcc_s.so.1 sits in
build/gcc/, and the host g++ resolves its libstdc++'s ld script
"GROUP ( libgcc_s.so.1 -lgcc )" against the cwd first, binding the REDOX
libgcc, which carries no GCC_4.3.0 soft-float symbols.
The recipe already defined _rb_linker_for_build for exactly this and never
passed it to make -- dead code. BUILD_LDFLAGS and BUILD_CPPFLAGS do not
exist in the TOP-LEVEL Makefile (they are gcc/Makefile variables), so a
top-level `make BUILD_LDFLAGS=...` never reaches the gcc sub-make.
CXX_FOR_BUILD does: the top level defines it and forwards it to every
sub-make, and gcc/Makefile.in:870 sets LINKER_FOR_BUILD = $(CXX_FOR_BUILD).
Confirmed with `make -n all-gcc` before changing anything.
The in-recipe note claiming LINKER_FOR_BUILD was tried and did not reach is
superseded: it reaches from inside build/gcc; the problem was propagation
from the top level.
Sequencing all-gcc first does NOT remove the cause, contrary to the older
comment -- it only holds for a clean build. This failure hit during all-gcc
before any target library was rebuilt, because a previous run had already
left libgcc_s.so.1 behind. Recipes must rebuild correctly on a dirty
target/, so the flag is the fix; sequencing stays as defence in depth.
2. Both C++23 modules were silently dropped. src/c++23/Makefile retries with an
EMPTIED std.cc when the compile fails, so the build exited 0 having shipped
no std.gcm or std.compat.gcm, with 41 'fenv_t has not been declared' errors
in the log.
#include_next <fenv.h> from the new libstdc++ wrapper resolved to the PREFIX
toolchain's installed copy of the same wrapper, guarded by the same
_GLIBCXX_FENV_H the new one had already defined -- so its body was skipped,
relibc's <fenv.h> was never reached, and every `using ::` below failed.
relibc is not at fault: the header compiles cleanly in C and C++ on its own.
Stock GCC builds target libraries with the in-tree compiler, which carries
-nostdinc++. Here CXX is the prefix compiler, so CXX_FOR_TARGET is plain and
the installed C++ headers stay on the search path. Fixed with
CXXFLAGS_FOR_TARGET, a top-level variable that reaches std.lo through
LTCXXCOMPILE, set before configure so the generated Makefiles carry it.
Verified: 41 errors -> 0, both "Cannot compile ... module" lines gone,
std.gcm and std.compat.gcm produced, std.cc/std.compat.cc 4502/795 lines
rather than emptied, libstdc++.modules.json staged.
Shipping this as an accepted limitation would have been a STUB AND
WORKAROUND POLICY violation regardless of GCC's Makefile being what empties
the source.
3. Changing CXX_FOR_BUILD makes autoconf refuse against an existing build dir
("`CXX' has changed since the previous run" in build-*/libcpp), since the
top level exports it as CXX into the build-side configure environment. That
is autoconf working correctly; documented, with the clean-build requirement.
Also records the subdirectories configure declines to build in this Canadian
cross (libatomic, libgomp, libsanitizer, libbacktrace among them) as an open
capability gap needing an operator decision, rather than leaving it unstated.
Carries earlier uncommitted working-tree changes to this recipe that the build
depends on (the CPPFLAGS sysroot strip, BUILD_CPPFLAGS restatement, static
libstdc++ staging, and the GCC 16 move).