Skip to content

crosstools: Fix host GCC char8_t bootstrap issue in libcody and clean binutils 2.32 patch - #1024

Open
metaneutrons wants to merge 1 commit into
aros-development-team:masterfrom
metaneutrons:pr/crosstools-libcody-fix
Open

crosstools: Fix host GCC char8_t bootstrap issue in libcody and clean binutils 2.32 patch#1024
metaneutrons wants to merge 1 commit into
aros-development-team:masterfrom
metaneutrons:pr/crosstools-libcody-fix

Conversation

@metaneutrons

Copy link
Copy Markdown
Contributor

Summary

Fixes cross-compiler bootstrap build failures when compiling AROS on modern Linux/macOS host systems equipped with recent compilers (GCC 14/15/16, modern Clang) where C++20 char8_t strict typing is enabled by default.

Details

  • libcody char8_t conversion: Adds #if __cpp_char8_t >= 201811L inline char S2C(char8_t c) { return static_cast<char>(c); } to gcc-15.2.0-aros.diff and gcc-16.2.0-aros.diff. This resolves type mismatch errors in libcody/buffer.cc during the host stage of the toolchain build.
  • Binutils 2.32 patch cleanup: Removes a duplicate file creation hunk (ld/emulparams/armelfb_aros.sh) in binutils-2.32-aros.diff which caused patch application failures with modern patch utilities.

Testing

  • Verified clean patch application and build on modern host compilers.

@metaneutrons
metaneutrons marked this pull request as ready for review August 19, 2026 17:13
Copilot AI lite review requested due to automatic review settings August 19, 2026 17:13

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@metaneutrons
metaneutrons force-pushed the pr/crosstools-libcody-fix branch from de97b51 to f5de027 Compare August 19, 2026 18:44
@Kalamatee

Kalamatee commented Aug 23, 2026

Copy link
Copy Markdown
Member

Thanks for looking at this. I tested all three hunks against the base commit of this PR (44336e404a6e). The binutils change needs reverting, and the two libcody changes need rework. Details below.

binutils 2.32: the removed hunk is not a duplicate, and removing it breaks ld

The description says the hunk is "a duplicate file creation hunk ... which caused patch application failures with modern patch utilities". I could not reproduce either half of that.

It is not a duplicate. In the base blob there is exactly one diff -ruN / --- / +++ triple for armelfb_aros.sh, at lines 622 to 624. Checking every file header in the patch for repeats:

=== duplicated file headers in binutils-2.32-aros.diff (count > 1) ===
(none listed above = no duplicates)

=== total file hunks: 30 ===

It applies cleanly. Pristine binutils 2.32, GNU patch 2.8, using the same invocation the build uses (patch -Z -E -f -p1, from BINUTILS_MAINPATCHSPECS = ...:-f,-p1 plus the patch -Z -E in scripts/fetch.sh):

=== applying UNMODIFIED base patch with AROS's flags (patch 2.8) ===
exit=0
--- failures/rejects ---
--- armelfb_aros.sh created? ---
-rw-r--r-- 1 kalamatee kalamatee 154 Jul 31 15:55 ld/emulparams/armelfb_aros.sh

Applying this PR's version to a pristine tree removes the file but leaves all four references to it:

=== armelfb_aros.sh after PR patch: ===
  MISSING
=== still referenced by: ===
ld/Makefile.in:668:	earmelfb_aros.c \
ld/Makefile.in:1240:@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/earmelfb_aros.Po@am__quote@
ld/Makefile.in:2396:earmelfb_aros.c: $(srcdir)/emulparams/armelfb_aros.sh \
ld/configure.tgt:136:			targ_extra_emuls=armelfb_aros

ld/Makefile.in:2396 is the generation rule and its first prerequisite is the deleted file, so make stops:

make: *** No rule to make target 'emulparams/armelfb_aros.sh', needed by 'earmelfb_aros.c'.  Stop.

Two things make this wider than a big-endian corner case. config/binutils_def contains 2.32, so this is the default binutils for every target except riscv and riscv64, which carry their own binutils_def. And configure.tgt sets targ_extra_emuls=armelfb_aros for arm*-*-aros*, which matches little-endian arm-aros too, so the emulation is built for all ARM targets. It is also inconsistent with the rest of the tree, since all six patches (2.32, 2.35, 2.38, 2.40, 2.45, 2.47) create this file.

On what you may have hit: AROS records applied patches with .<patchname>.applied stamp files in patch_cached (scripts/fetch.sh). If the stamp and the Ports tree get out of step, for example after an interrupted or partially cleaned build, patch runs again over an already patched tree and reports "Reversed (or previously applied) patch detected". Since the spec passes -f, that is forced through rather than stopping, which reads a lot like a duplicate hunk. I hit that signature by accident during testing by extracting the tarball over an already patched tree. The fix in that case is clearing the Ports tree and the .applied stamp, not dropping the hunk.

Could you restore this file? If the goal is really to drop big-endian ARM, that needs doing completely and across all six patches, including the BFD side (elf32-bigarm-aros and arm_elf32_aros_be_vec, at patch lines 157, 459 and 463), which is a much larger change.

gcc 16.2.0 libcody: not needed

Upstream 16.2.0 already handles this. libcody/cody.hh contains:

#if __cpp_char8_t >= 201811
template<unsigned I>
constexpr char S2C (char8_t const (&s)[I]) { ... }
#else
template<unsigned I>
constexpr char S2C (char const (&s)[I]) { ... }
#endif

along with AppendWord (char8_t const *str, ...) and Packet (unsigned c, const char8_t *s). Verified in the released source (gcc-mirror/gcc, tag releases/gcc-16.2.0) and in the copy in the local Ports tree.

The added function could not take effect in any case:

  1. It is at global scope, but the calls are inside namespace Cody { namespace Detail { in buffer.cc, and cody.hh:122 calls it as Detail::S2C(u8" "). Unqualified lookup finds Detail::S2C in the nearest enclosing namespace and stops there, and the qualified call cannot reach ::S2C at all.
  2. The parameter is a single char8_t, but every call site passes u8"...", which is const char8_t[2]. An array does not convert to char8_t.
  3. It is placed before #include "cody.hh", so before namespace Detail exists.

It also lands between the copyright line and // License: Apache v2.0, splitting the upstream banner.

gcc 15.2.0 libcody: real problem, but this fix cannot work

This one is chasing something real. 15.2.0 has no char8_t handling:

// C++11 doesn't have utf8 character literals :(
template<unsigned I>
constexpr char S2C (char const (&s)[I])

while cody.hh:113 does Append (Detail::S2C(u8" "));. With a host compiler where char8_t is enabled, u8" " is const char8_t[2] and there is no viable overload, matching your description.

The three points above still apply, plus a fourth that settles it: the failing calls are in cody.hh itself, which every libcody translation unit includes, so patching buffer.cc cannot fix them.

The fix is to backport what upstream did for 16.x, into cody.hh. The following was generated by diffing 15.2.0 against 16.2.0 and verified to apply cleanly with patch -p1:

--- gcc-15.2.0/libcody/cody.hh
+++ gcc-15.2.0.aros/libcody/cody.hh
@@ -47,12 +47,21 @@
 
 // C++11 doesn't have utf8 character literals :(
 
+#if __cpp_char8_t >= 201811
+template<unsigned I>
+constexpr char S2C (char8_t const (&s)[I])
+{
+  static_assert (I == 2, "only single octet strings may be converted");
+  return s[0];
+}
+#else
 template<unsigned I>
 constexpr char S2C (char const (&s)[I])
 {
   static_assert (I == 2, "only single octet strings may be converted");
   return s[0];
 }
+#endif
 
 /// Internal buffering class.  Used to concatenate outgoing messages
 /// and Lex incoming ones.
@@ -123,6 +132,13 @@
       Space ();
     Append (str, maybe_quote, len);
   }
+#if __cpp_char8_t >= 201811
+  void AppendWord (char8_t const *str, bool maybe_quote = false,
+		   size_t len = ~size_t (0))
+  {
+    AppendWord ((const char *) str, maybe_quote, len);
+  }
+#endif
   /// Add a word as with AppendWord
   /// @param str the string to append
   /// @param maybe_quote string might need quoting, as for Append
@@ -264,6 +280,12 @@
     : string (s), cat (STRING), code (c)
   {
   }
+#if __cpp_char8_t >= 201811
+  Packet (unsigned c, const char8_t *s)
+    : string ((const char *) s), cat (STRING), code (c)
+  {
+  }
+#endif
   Packet (unsigned c, std::vector<std::string> &&v)
     : vector (std::move (v)), cat (VECTOR), code (c)
   {

Upstream writes the guard as >= 201811 without the L suffix, worth matching so later diffs against upstream stay clean.

Summary

  • Restore the armelfb_aros.sh hunk in binutils-2.32-aros.diff.
  • Drop the gcc-16.2.0-aros.diff hunk, since upstream already carries the fix.
  • Replace the gcc-15.2.0-aros.diff hunk with the cody.hh backport above.

If you can post the exact compiler error you saw for 15.2.0, that would confirm the backport covers it, since there may be further call sites in client.cc or server.cc worth checking at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants