[Buildroot] [PATCH 00/11] Add ColdFire MCF5441x (m68k) support

[Buildroot] [PATCH 00/11] Add ColdFire MCF5441x (m68k) support

[Jean-Michel Hautbois]

This series adds support for the NXP ColdFire MCF5441x family (m68k/cf
subarch) in Buildroot, and fixes a set of package build and runtime
issues that surface when targeting this CPU.

MCF5441x (MMU, ColdFire V4e core, typically 250 MHz, no hardware FPU, no
SMP, no TLS, no atomic builtins) is not well exercised by the existing
m68k coverage. Building a minimal userland (busybox, openssl, nginx,
dropbear, ntp) on top of uClibc-ng exposed the fixes gathered in this
series.

The series can be grouped as follows:

 * Arch and global flags
   - arch/Config.in.m68k: new BR2_m68k_cf5441x subarch entry
   - package/gcc: force --with-arch=cf on MCF5441x so internal
     multilibs are driven by the ColdFire ISA, not m68k-classic
   - package/Makefile.in: add ColdFire workaround flags (mxgot, etc.)
     consumed by multiple packages

 * Toolchain companions
   - package/gdb: use static libgcc on ColdFire to avoid runtime
     libgcc_s ABI mismatch
   - package/gmp: disable C++ bindings on ColdFire (libstdc++ is not
     available on this target flavour)

 * Network stack
   - package/libopenssl: extend ColdFire handling (OPENSSL_NO_ATOMICS,
     OPENSSL_NO_ASM, OPENSSL_SMALL_FOOTPRINT, mxgot)
   - package/dropbear: disable ML-KEM768 which triggers an ICE in gcc
     14 on m68k
   - package/ntp: link libatomic when the toolchain provides it, so
     64 bit atomics resolve at link time
   - package/nginx: propagate ColdFire TLS/atomic settings

 * Misc
   - package/mawk: create the awk symlink on install so scripts relying
     on /usr/bin/awk keep working
   - package/libglib2: add ColdFire conditional tweaks needed for the
     target build

The series has been validated on real hardware (Freescale/NXP MCF54418
based ColdFire V4e board, 250 MHz, 256 MiB DDR, uClibc-ng) via a
buildroot initramfs image: kernel boot, openssl, nginx, dropbear and
ntpd all start cleanly with the compiled flags visible in
"openssl version -a" (mxgot, OPENSSL_NO_ATOMICS, OPENSSL_NO_ASM).

The series applies cleanly on top of current master. No regressions
expected on other m68k variants (mcf5208, q800) or other arches; the
changes are all guarded by BR2_m68k_cf or MCF5441x conditionals.

Thanks for the review.

Jean-Michel Hautbois (11):
  arch/Config.in.m68k: add ColdFire MCF5441x support
  package/gcc: force --with-arch=cf on m68k MCF5441x
  package/Makefile.in: add global ColdFire workaround flags
  package/gmp: disable C++ bindings on m68k ColdFire
  package/gdb: use static libgcc on m68k ColdFire
  package/libopenssl: extend m68k ColdFire support
  package/dropbear: disable ML-KEM768 on m68k
  package/ntp: Link libatomic when available
  package/nginx: add m68k ColdFire TLS support
  package/mawk: create awk symlink on install
  package/libglib2: add m68k ColdFire support

 arch/Config.in.m68k              |  7 +++++++
 package/Makefile.in              |  4 ++++
 package/dropbear/dropbear.mk     |  7 +++++++
 package/gcc/gcc.mk               |  4 ++++
 package/gdb/gdb.mk               |  5 +++++
 package/gmp/gmp.mk               |  4 +++-
 package/libglib2/libglib2.mk     | 11 ++++++++++-
 package/libopenssl/libopenssl.mk |  3 +++
 package/mawk/mawk.mk             |  6 ++++++
 package/nginx/nginx.mk           |  6 ++++++
 package/ntp/ntp.mk               |  5 +++++
 11 files changed, 60 insertions(+), 2 deletions(-)

-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 01/11] arch/Config.in.m68k: add ColdFire MCF5441x support

[Jean-Michel Hautbois]

Add the MCF5441x (54418) ColdFire V4e variant to the m68k architecture
menu. The 5441x selects BR2_m68k_cf, BR2_USE_MMU (V4e has an MMU, unlike
the 5208) and BR2_SOFT_FLOAT (no hardware FPU). The GCC target CPU is
set to 54418.

qemu-system-m68k does not emulate the 5441x family, so no qemu
defconfig is added; the existing qemu_m68k_mcf5208_defconfig and
qemu_m68k_q800_defconfig are not affected.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 arch/Config.in.m68k | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/Config.in.m68k b/arch/Config.in.m68k
index 235cafacf5..b281f43a30 100644
--- a/arch/Config.in.m68k
+++ b/arch/Config.in.m68k
@@ -38,12 +38,19 @@ config BR2_m68k_cf5208
 	select BR2_m68k_cf
 	select BR2_SOFT_FLOAT
 
+config BR2_m68k_cf5441x
+	bool "5441x"
+	select BR2_m68k_cf
+	select BR2_USE_MMU
+	select BR2_SOFT_FLOAT
+
 endchoice
 
 config BR2_GCC_TARGET_CPU
 	default "68030"		if BR2_m68k_68030
 	default "68040"		if BR2_m68k_68040
 	default "5208"		if BR2_m68k_cf5208
+	default "54418"		if BR2_m68k_cf5441x
 
 config BR2_READELF_ARCH_NAME
 	default "MC68000"
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 02/11] package/gcc: force --with-arch=cf on m68k MCF5441x

[Jean-Michel Hautbois]

On m68k ColdFire V4e (MCF5441x) with BR2_USE_MMU selected, the
host-gcc build fails during the multilib pass because the compiler
cannot disambiguate between m68k and cf variants. It needs to be
configured explicitly with --with-arch=cf.

The natural place to wire this would be BR2_GCC_TARGET_ARCH="cf" in
arch/Config.in.m68k (as was attempted in an earlier v1 submission
[1], see the v1 review at [2]). That mechanism is however also
consumed by the external toolchain infrastructure: when
BR2_GCC_TARGET_ARCH is non-empty,
toolchain/toolchain-external/pkg-toolchain-external.mk unconditionally
adds -march=$(GCC_TARGET_ARCH) to TOOLCHAIN_EXTERNAL_CFLAGS and bakes
it into the toolchain wrapper as the default BR_ARCH.

This is fine as long as the value is a valid -march= argument, but
gcc m68k only accepts 68000/68010/68020/68030/68040/68060/cpu32/isaa
/isaaplus/isab/isac on the command line; "cf" is a valid --with-arch
value for configure, but not a valid -march. The result is that an
external toolchain user selecting BR2_m68k_cf5441x gets the wrapper
injecting -march=cf on every compile, which immediately fails with
"unrecognized argument in option '-march=cf'". This was confirmed by
consuming a Buildroot-generated cf5441x toolchain as external.

Instead, add the --with-arch=cf configure argument via Buildroot's
gcc packaging Makefile (package/gcc/gcc.mk), gated on
BR2_m68k_cf5441x. Only the internal host-gcc configure step picks
it up; BR2_GCC_TARGET_ARCH remains unset, so the external toolchain
infrastructure is untouched and external toolchain users are not
affected by this patch.

[1] https://lore.kernel.org/buildroot/20230629053130.3976-1-jeanmichel.hautbois@yoseli.org/
[2] https://lore.kernel.org/buildroot/20230704052449.GM2510@scaer/

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/gcc/gcc.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index ea96286c32..270a0638d9 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -220,6 +220,10 @@ endif
 ifneq ($(GCC_TARGET_ARCH),)
 HOST_GCC_COMMON_CONF_OPTS += --with-arch="$(GCC_TARGET_ARCH)"
 endif
+
+ifeq ($(BR2_m68k_cf5441x),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-arch=cf
+endif
 ifneq ($(GCC_TARGET_ABI),)
 HOST_GCC_COMMON_CONF_OPTS += --with-abi="$(GCC_TARGET_ABI)"
 endif
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 03/11] package/Makefile.in: add global ColdFire workaround flags

[Jean-Michel Hautbois]

GCC's instruction scheduler on m68k ColdFire reorders memory accesses
in ways that break code assuming sequential memory ordering. This was
observed in uClibc-ng's elf_machine_relative and in OpenSSL's internal
state management after fork().

Additionally, ColdFire uses 16-bit offsets for switch statement jump
tables by default. Large functions such as pcre2_match() and nftables
rule evaluation overflow this limit, causing assembler errors.

Add -fno-schedule-insns, -fno-schedule-insns2, and
-mlong-jump-table-offsets globally for BR2_m68k_cf, alongside the
existing -fno-dwarf2-cfi-asm workaround.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/Makefile.in | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/Makefile.in b/package/Makefile.in
index 5ebb5f9ba8..42dd79118d 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -211,6 +211,10 @@ TARGET_FCFLAGS = $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
 ifeq ($(BR2_m68k_cf),y)
 TARGET_CFLAGS += -fno-dwarf2-cfi-asm
 TARGET_CXXFLAGS += -fno-dwarf2-cfi-asm
+TARGET_CFLAGS += -fno-schedule-insns -fno-schedule-insns2
+TARGET_CXXFLAGS += -fno-schedule-insns -fno-schedule-insns2
+TARGET_CFLAGS += -mlong-jump-table-offsets
+TARGET_CXXFLAGS += -mlong-jump-table-offsets
 endif
 
 ifeq ($(BR2_BINFMT_FLAT),y)
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 04/11] package/gmp: disable C++ bindings on m68k ColdFire

[Jean-Michel Hautbois]

On m68k ColdFire, libgcc.a exports __sync_* atomic built-in functions
as hidden symbols. When GMP's C++ bindings are enabled, libgmpxx.so
links against libstdc++ which references these hidden symbols, causing
a linker error:

  hidden symbol '__sync_val_compare_and_swap_4' in libgcc.a is
  referenced by DSO

Disable C++ bindings on m68k ColdFire. The C library (libgmp.so) is
unaffected.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/gmp/gmp.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/package/gmp/gmp.mk b/package/gmp/gmp.mk
index 07aa4aefdf..8dd60fd2a0 100644
--- a/package/gmp/gmp.mk
+++ b/package/gmp/gmp.mk
@@ -31,7 +31,9 @@ ifeq ($(BR2_riscv):$(BR2_RISCV_ISA_RVM),y:)
 GMP_CONF_OPTS += --disable-assembly
 endif
 
-ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
+ifeq ($(BR2_m68k_cf),y)
+GMP_CONF_OPTS += --disable-cxx
+else ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
 GMP_CONF_OPTS += --enable-cxx
 else
 GMP_CONF_OPTS += --disable-cxx
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 05/11] package/gdb: use static libgcc on m68k ColdFire

[Jean-Michel Hautbois]

On m68k ColdFire, libgcc.a exports __sync_* atomic built-in functions
as hidden symbols. GDB links against libstdc++ which references these
symbols, causing linker errors when building as a dynamically linked
executable.

Use -static-libstdc++ and -static-libgcc to avoid the hidden symbol
issue.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/gdb/gdb.mk | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/package/gdb/gdb.mk b/package/gdb/gdb.mk
index 1841002dc1..c6dfcf3bef 100644
--- a/package/gdb/gdb.mk
+++ b/package/gdb/gdb.mk
@@ -116,6 +116,11 @@ GDB_MAKE_ENV += \
 GDB_CONF_ENV += gdb_cv_prfpregset_t_broken=no
 GDB_MAKE_ENV += gdb_cv_prfpregset_t_broken=no
 
+ifeq ($(BR2_m68k_cf),y)
+GDB_CONF_ENV += LDFLAGS="-static-libstdc++ -static-libgcc"
+GDB_MAKE_ENV += LDFLAGS="-static-libstdc++ -static-libgcc"
+endif
+
 # We want the built-in libraries of gdb (libbfd, libopcodes) to be
 # built and linked statically, as we do not install them on the
 # target, to not clash with the ones potentially installed by
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 06/11] package/libopenssl: extend m68k ColdFire support

[Jean-Michel Hautbois]

ColdFire has no hardware atomic instructions. Disable OpenSSL's
atomic operations and inline assembly which assume a different m68k
variant, and add -fno-strict-aliasing to prevent GCC from optimizing
away type-punned pointer accesses used in OpenSSL internals.

Link with libatomic for the 64-bit atomic operations that OpenSSL 3.x
requires, and force the linux-generic32 target to avoid arch-specific
assembly paths.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/libopenssl/libopenssl.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk
index bd4b889c88..6009cbb345 100644
--- a/package/libopenssl/libopenssl.mk
+++ b/package/libopenssl/libopenssl.mk
@@ -23,6 +23,9 @@ ifeq ($(BR2_m68k_cf),y)
 LIBOPENSSL_CFLAGS += -mxgot
 # resolves an assembler "out of range error" with blake2 and sha512 algorithms
 LIBOPENSSL_CFLAGS += -DOPENSSL_SMALL_FOOTPRINT
+LIBOPENSSL_CFLAGS += -DOPENSSL_NO_ATOMICS -DOPENSSL_NO_ASM -fno-strict-aliasing
+LIBOPENSSL_CONF_ENV += LDFLAGS="-latomic"
+LIBOPENSSL_TARGET_ARCH = linux-generic32
 endif
 
 ifeq ($(BR2_USE_MMU),)
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 07/11] package/dropbear: disable ML-KEM768 on m68k

[Jean-Michel Hautbois]

ML-KEM768 post-quantum key exchange code (in the vendored header
src/libcrux_mlkem768_sha3.h) triggers a GCC internal compiler error
(ICE) in cselib_record_set during the postreload CSE pass on m68k.
Reproduced on m68k-buildroot-linux-uclibc (cf5441x, -O2) with both
GCC 14.3.0 (the current Buildroot default for m68k) and GCC 15.2.0.

The failing pass backtrace is:
  reload_cse_regs_1
  -> pass_postreload_cse::execute
     -> cselib_process_insn
        -> cselib_record_sets
           -> cselib_record_set  (cselib.cc:2869 on gcc 15)

Disable ML-KEM768 via localoptions.h on m68k until the GCC bug is
resolved. Standard key exchange algorithms remain available.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/dropbear/dropbear.mk | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/package/dropbear/dropbear.mk b/package/dropbear/dropbear.mk
index e4e42cf994..52bc15e346 100644
--- a/package/dropbear/dropbear.mk
+++ b/package/dropbear/dropbear.mk
@@ -62,6 +62,13 @@ endef
 DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_SVR_PASSWORD_AUTH
 endif
 
+ifeq ($(BR2_m68k),y)
+define DROPBEAR_DISABLE_MLKEM
+	echo '#define DROPBEAR_MLKEM768 0'               >> $(@D)/localoptions.h
+endef
+DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_DISABLE_MLKEM
+endif
+
 ifeq ($(BR2_PACKAGE_DROPBEAR_LEGACY_CRYPTO),y)
 define DROPBEAR_ENABLE_LEGACY_CRYPTO
 	echo '#define DROPBEAR_3DES 1'                  >> $(@D)/localoptions.h
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 08/11] package/ntp: Link libatomic when available

[Jean-Michel Hautbois]

NTP uses 64-bit atomic operations that GCC emits as calls to
__atomic_* runtime helpers on 32-bit targets without native 64-bit
atomic instructions (e.g. m68k). Without explicit linking, the link
step fails with undefined references.

Gate on BR2_TOOLCHAIN_HAS_LIBATOMIC (same pattern as dhcp, tor,
libcurl). Keeps uClibc/uClinux toolchains happy: they do not ship
libatomic but provide the helpers in the C library.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/ntp/ntp.mk | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk
index f481c5d79b..eb9bfff85c 100644
--- a/package/ntp/ntp.mk
+++ b/package/ntp/ntp.mk
@@ -17,6 +17,11 @@ NTP_CPE_ID_VERSION = $(NTP_VERSION_MAJOR).$(NTP_VERSION_MINOR)
 NTP_CPE_ID_UPDATE = p$(NTP_VERSION_POINT)
 NTP_SELINUX_MODULES = ntp
 NTP_CONF_ENV = ac_cv_lib_md5_MD5Init=no POSIX_SHELL=/bin/sh
+
+ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
+NTP_CONF_ENV += LIBS="-latomic"
+endif
+
 NTP_CONF_OPTS = \
 	--with-shared \
 	--program-transform-name=s,,, \
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 09/11] package/nginx: add m68k ColdFire TLS support

[Jean-Michel Hautbois]

On m68k ColdFire, nginx with OpenSSL requires reduced optimization
(-O1) and -fno-strict-aliasing to avoid aliasing violations in the
OpenSSL/nginx interaction that cause segfaults in HTTPS handling.

Also enforce strict alignment (-mstrict-align) and explicitly link
against the system crypto libraries including libatomic.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/nginx/nginx.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/nginx/nginx.mk b/package/nginx/nginx.mk
index 41490caee2..35d53c3ec1 100644
--- a/package/nginx/nginx.mk
+++ b/package/nginx/nginx.mk
@@ -87,6 +87,12 @@ else
 NGINX_CONF_OPTS += --without-pcre
 endif
 
+ifeq ($(BR2_m68k_cf),y)
+NGINX_CFLAGS += -O1 -fno-strict-aliasing -mstrict-align
+NGINX_CONF_ENV += LIBS="-lssl -lcrypto -lz -ldl -lpcre"
+NGINX_CONF_OPTS += --with-ld-opt="-L$(STAGING_DIR)/usr/lib -lssl -lcrypto -lpcre2-8 -latomic -lz -ldl -lpthread"
+endif
+
 # modules disabled or not activated because of missing dependencies:
 # - google_perftools  (googleperftools)
 # - http_perl_module  (host-perl)
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 10/11] package/mawk: create awk symlink on install

[Jean-Michel Hautbois]

Many scripts and Makefiles expect 'awk' to be available in PATH.
When mawk is the only awk implementation installed, create a symlink
from awk to mawk so that these scripts work without modification.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/mawk/mawk.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/mawk/mawk.mk b/package/mawk/mawk.mk
index f9f0623904..b21ac16742 100644
--- a/package/mawk/mawk.mk
+++ b/package/mawk/mawk.mk
@@ -10,4 +10,10 @@ MAWK_SOURCE = mawk-$(MAWK_VERSION).tgz
 MAWK_LICENSE = GPL-2.0
 MAWK_LICENSE_FILES = COPYING
 
+define MAWK_CREATE_SYMLINK
+	ln -sf mawk $(TARGET_DIR)/usr/bin/awk
+endef
+
+MAWK_POST_INSTALL_TARGET_HOOKS += MAWK_CREATE_SYMLINK
+
 $(eval $(autotools-package))
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 11/11] package/libglib2: add m68k ColdFire support

[Jean-Michel Hautbois]

On m68k ColdFire, libgio exceeds the default 16-bit GOT entry limit
(8192 entries). Add -mxgot to use 32-bit GOT offsets.

Also enable b_staticpic=true to allow linking static internal
libraries (girepository-internals) into shared libraries
(libgirepository), which requires position-independent code.

Disable sysprof profiling support which is not useful on embedded
targets and adds unnecessary build complexity.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
 package/libglib2/libglib2.mk | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/package/libglib2/libglib2.mk b/package/libglib2/libglib2.mk
index cae8a85a28..8f8360e635 100644
--- a/package/libglib2/libglib2.mk
+++ b/package/libglib2/libglib2.mk
@@ -55,12 +55,17 @@ endif
 # containing ${libdir} in gio-2.0.pc. Indeed, a value depending on
 # ${libdir} would be prefixed by the sysroot by pkg-config, causing a
 # bogus installation path once combined with $(DESTDIR).
+ifeq ($(BR2_m68k_cf),y)
+LIBGLIB2_CFLAGS += -mxgot
+endif
+
 LIBGLIB2_CONF_OPTS = \
 	-Dglib_debug=disabled \
 	-Dlibelf=disabled \
 	-Dgio_module_dir=/usr/lib/gio/modules \
 	-Dtests=false \
-	-Doss_fuzz=disabled
+	-Doss_fuzz=disabled \
+	-Dsysprof=disabled
 
 LIBGLIB2_MESON_EXTRA_PROPERTIES = \
 	have_c99_vsnprintf=true \
@@ -118,6 +123,10 @@ else
 LIBGLIB2_CONF_OPTS += -Dlibmount=disabled
 endif
 
+ifeq ($(BR2_m68k_cf),y)
+LIBGLIB2_CONF_OPTS += -Db_staticpic=true
+endif
+
 # Purge useless binaries from target
 define LIBGLIB2_REMOVE_DEV_FILES
 	rm -rf $(TARGET_DIR)/usr/lib/glib-2.0
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 07/11] package/dropbear: disable ML-KEM768 on m68k

[Baruch Siach via buildroot]

Hi Jean-Michel,

On Fri, Apr 24 2026, Jean-Michel Hautbois wrote:
> ML-KEM768 post-quantum key exchange code (in the vendored header
> src/libcrux_mlkem768_sha3.h) triggers a GCC internal compiler error
> (ICE) in cselib_record_set during the postreload CSE pass on m68k.
> Reproduced on m68k-buildroot-linux-uclibc (cf5441x, -O2) with both
> GCC 14.3.0 (the current Buildroot default for m68k) and GCC 15.2.0.
>
> The failing pass backtrace is:
>   reload_cse_regs_1
>   -> pass_postreload_cse::execute
>      -> cselib_process_insn
>         -> cselib_record_sets
>            -> cselib_record_set  (cselib.cc:2869 on gcc 15)
>
> Disable ML-KEM768 via localoptions.h on m68k until the GCC bug is
> resolved. Standard key exchange algorithms remain available.

Common practice for GCC bugs is to add a BR2_TOOLCHAIN_HAS_GCC_BUG_[id]
config symbol to toolchain/Config.in, and use that symbol to activate
bug specific workaround. [id] refers to GCC Bugzilla bug ID. This makes
it easier to track the GCC versions this bug affects.

baruch

>
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> ---
>  package/dropbear/dropbear.mk | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/package/dropbear/dropbear.mk b/package/dropbear/dropbear.mk
> index e4e42cf994..52bc15e346 100644
> --- a/package/dropbear/dropbear.mk
> +++ b/package/dropbear/dropbear.mk
> @@ -62,6 +62,13 @@ endef
>  DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_SVR_PASSWORD_AUTH
>  endif
>  
> +ifeq ($(BR2_m68k),y)
> +define DROPBEAR_DISABLE_MLKEM
> +	echo '#define DROPBEAR_MLKEM768 0'               >> $(@D)/localoptions.h
> +endef
> +DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_DISABLE_MLKEM
> +endif
> +
>  ifeq ($(BR2_PACKAGE_DROPBEAR_LEGACY_CRYPTO),y)
>  define DROPBEAR_ENABLE_LEGACY_CRYPTO
>  	echo '#define DROPBEAR_3DES 1'                  >> $(@D)/localoptions.h

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 07/11] package/dropbear: disable ML-KEM768 on m68k

[Jean-Michel Hautbois]

Hi Baruch,

Le 24/04/2026 à 16:11, Baruch Siach a écrit :
> Hi Jean-Michel,
> 
> On Fri, Apr 24 2026, Jean-Michel Hautbois wrote:
>> ML-KEM768 post-quantum key exchange code (in the vendored header
>> src/libcrux_mlkem768_sha3.h) triggers a GCC internal compiler error
>> (ICE) in cselib_record_set during the postreload CSE pass on m68k.
>> Reproduced on m68k-buildroot-linux-uclibc (cf5441x, -O2) with both
>> GCC 14.3.0 (the current Buildroot default for m68k) and GCC 15.2.0.
>>
>> The failing pass backtrace is:
>>    reload_cse_regs_1
>>    -> pass_postreload_cse::execute
>>       -> cselib_process_insn
>>          -> cselib_record_sets
>>             -> cselib_record_set  (cselib.cc:2869 on gcc 15)
>>
>> Disable ML-KEM768 via localoptions.h on m68k until the GCC bug is
>> resolved. Standard key exchange algorithms remain available.
> 
> Common practice for GCC bugs is to add a BR2_TOOLCHAIN_HAS_GCC_BUG_[id]
> config symbol to toolchain/Config.in, and use that symbol to activate
> bug specific workaround. [id] refers to GCC Bugzilla bug ID. This makes
> it easier to track the GCC versions this bug affects.

Thanks for the pointer !
I just filed a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125078

I will prepare a v2 for this patch with a BR2_TOOLCHAIN_HAS_GCC_BUG_125078

I will wait a bit before a v2 as maybe other patches will have 
remarks/issues.

Thanks !
JM

> baruch
> 
>>
>> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
>> ---
>>   package/dropbear/dropbear.mk | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/package/dropbear/dropbear.mk b/package/dropbear/dropbear.mk
>> index e4e42cf994..52bc15e346 100644
>> --- a/package/dropbear/dropbear.mk
>> +++ b/package/dropbear/dropbear.mk
>> @@ -62,6 +62,13 @@ endef
>>   DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_SVR_PASSWORD_AUTH
>>   endif
>>   
>> +ifeq ($(BR2_m68k),y)
>> +define DROPBEAR_DISABLE_MLKEM
>> +	echo '#define DROPBEAR_MLKEM768 0'               >> $(@D)/localoptions.h
>> +endef
>> +DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_DISABLE_MLKEM
>> +endif
>> +
>>   ifeq ($(BR2_PACKAGE_DROPBEAR_LEGACY_CRYPTO),y)
>>   define DROPBEAR_ENABLE_LEGACY_CRYPTO
>>   	echo '#define DROPBEAR_3DES 1'                  >> $(@D)/localoptions.h
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 02/11] package/gcc: force --with-arch=cf on m68k MCF5441x

[Thomas Petazzoni via buildroot]

Hello Jean-Michel,

Thanks for this work.

On Fri, Apr 24, 2026 at 03:23:17PM +0200, Jean-Michel Hautbois wrote:
> On m68k ColdFire V4e (MCF5441x) with BR2_USE_MMU selected, the
> host-gcc build fails during the multilib pass because the compiler
> cannot disambiguate between m68k and cf variants. It needs to be
> configured explicitly with --with-arch=cf.

I'm rather confused by "cannot disambiguate between m68k and cf
variants", isn't MCF5441x *only* a Coldfire processor?

Otherwise I think the change is OK, and the description is very
thorough and detailed.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 03/11] package/Makefile.in: add global ColdFire workaround flags

[Thomas Petazzoni via buildroot]

Hello Jean-Michel,

On Fri, Apr 24, 2026 at 03:23:18PM +0200, Jean-Michel Hautbois wrote:
> GCC's instruction scheduler on m68k ColdFire reorders memory accesses
> in ways that break code assuming sequential memory ordering. This was
> observed in uClibc-ng's elf_machine_relative and in OpenSSL's internal
> state management after fork().
> 
> Additionally, ColdFire uses 16-bit offsets for switch statement jump
> tables by default. Large functions such as pcre2_match() and nftables
> rule evaluation overflow this limit, causing assembler errors.
> 
> Add -fno-schedule-insns, -fno-schedule-insns2, and
> -mlong-jump-table-offsets globally for BR2_m68k_cf, alongside the
> existing -fno-dwarf2-cfi-asm workaround.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> ---
>  package/Makefile.in | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/package/Makefile.in b/package/Makefile.in
> index 5ebb5f9ba8..42dd79118d 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -211,6 +211,10 @@ TARGET_FCFLAGS = $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
>  ifeq ($(BR2_m68k_cf),y)
>  TARGET_CFLAGS += -fno-dwarf2-cfi-asm
>  TARGET_CXXFLAGS += -fno-dwarf2-cfi-asm
> +TARGET_CFLAGS += -fno-schedule-insns -fno-schedule-insns2
> +TARGET_CXXFLAGS += -fno-schedule-insns -fno-schedule-insns2
> +TARGET_CFLAGS += -mlong-jump-table-offsets
> +TARGET_CXXFLAGS += -mlong-jump-table-offsets

I'm not against this, but you're changing those flags for everyone
using Coldfire, not only for your new Coldfire processor. Is this the
right thing to do? Are those issues also affecting other Coldfire
processors, and nobody noticed until now because almost nobody uses
Coldfire?

I think this is the part that's a bit missing in your description:
give confidence that the BR2_m68k_cf is the right condition for this.

Regarding -mlong-jump-table-offsets should we do this globally, or on
a per package basis, like we do with -mxgot?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 04/11] package/gmp: disable C++ bindings on m68k ColdFire

[Thomas Petazzoni via buildroot]

On Fri, Apr 24, 2026 at 03:23:19PM +0200, Jean-Michel Hautbois wrote:
> On m68k ColdFire, libgcc.a exports __sync_* atomic built-in functions
> as hidden symbols. When GMP's C++ bindings are enabled, libgmpxx.so
> links against libstdc++ which references these hidden symbols, causing
> a linker error:
> 
>   hidden symbol '__sync_val_compare_and_swap_4' in libgcc.a is
>   referenced by DSO
> 
> Disable C++ bindings on m68k ColdFire. The C library (libgmp.so) is
> unaffected.

But isn't that a bug somewhere? Not sure if the bug is that libgcc.a
exports __sync built-ins as hidden symbols, or something else.

Also, why don't we see build failures on the autobuilders, for other
Coldfire processors? Is this affecting only your new Coldfire CPU, or
also other ones?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 05/11] package/gdb: use static libgcc on m68k ColdFire

[Thomas Petazzoni via buildroot]

Hello,

On Fri, Apr 24, 2026 at 03:23:20PM +0200, Jean-Michel Hautbois wrote:
> On m68k ColdFire, libgcc.a exports __sync_* atomic built-in functions
> as hidden symbols. GDB links against libstdc++ which references these
> symbols, causing linker errors when building as a dynamically linked
> executable.
> 
> Use -static-libstdc++ and -static-libgcc to avoid the hidden symbol
> issue.

A bit the same comment as on the previous patch. Is this an inherent
limitation? A bug?

Is this affecting all Coldfire processors? Only the brand new one?

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 06/11] package/libopenssl: extend m68k ColdFire support

[Thomas Petazzoni via buildroot]

Hello Jean-Michel,

On Fri, Apr 24, 2026 at 03:23:21PM +0200, Jean-Michel Hautbois wrote:
> ColdFire has no hardware atomic instructions. Disable OpenSSL's
> atomic operations and inline assembly which assume a different m68k
> variant, and add -fno-strict-aliasing to prevent GCC from optimizing
> away type-punned pointer accesses used in OpenSSL internals.
> 
> Link with libatomic for the 64-bit atomic operations that OpenSSL 3.x
> requires, and force the linux-generic32 target to avoid arch-specific
> assembly paths.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> ---
>  package/libopenssl/libopenssl.mk | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk
> index bd4b889c88..6009cbb345 100644
> --- a/package/libopenssl/libopenssl.mk
> +++ b/package/libopenssl/libopenssl.mk
> @@ -23,6 +23,9 @@ ifeq ($(BR2_m68k_cf),y)
>  LIBOPENSSL_CFLAGS += -mxgot
>  # resolves an assembler "out of range error" with blake2 and sha512 algorithms
>  LIBOPENSSL_CFLAGS += -DOPENSSL_SMALL_FOOTPRINT
> +LIBOPENSSL_CFLAGS += -DOPENSSL_NO_ATOMICS -DOPENSSL_NO_ASM -fno-strict-aliasing
> +LIBOPENSSL_CONF_ENV += LDFLAGS="-latomic"
> +LIBOPENSSL_TARGET_ARCH = linux-generic32

Why is this needed now? It is correctly building at least for existing
Coldfire platforms that we support (I believe).

If it needs -latomic, it would most likely need that on other
architectures like Sparc for which atomic built-ins are implemented in
libatomic.

So essentially the problem that I see with your patch that it is
"just" fixing your particular issue in your particular case, but not
really taking a step back and see to which cases which fix/workaround
should apply. For example the -fno-strict-aliasing thing, why is that
Coldfire specific?

Also, have a look at config BR2_PACKAGE_LIBOPENSSL_TARGET_ARCH, it
should already use "linux-generic32 no-asm", which is basically what
you're doing here. Except perhaps you have
BR2_TOOLCHAIN_HAS_LIBATOMIC, which is why "linux-latomic no-asm" gets
used instead?

As you can see, a bit more investigation is needed to have a cleaner
solution.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 08/11] package/ntp: Link libatomic when available

[Thomas Petazzoni via buildroot]

On Fri, Apr 24, 2026 at 03:23:23PM +0200, Jean-Michel Hautbois wrote:

> diff --git a/package/ntp/ntp.mk b/package/ntp/ntp.mk
> index f481c5d79b..eb9bfff85c 100644
> --- a/package/ntp/ntp.mk
> +++ b/package/ntp/ntp.mk
> @@ -17,6 +17,11 @@ NTP_CPE_ID_VERSION = $(NTP_VERSION_MAJOR).$(NTP_VERSION_MINOR)
>  NTP_CPE_ID_UPDATE = p$(NTP_VERSION_POINT)
>  NTP_SELINUX_MODULES = ntp
>  NTP_CONF_ENV = ac_cv_lib_md5_MD5Init=no POSIX_SHELL=/bin/sh
> +
> +ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
> +NTP_CONF_ENV += LIBS="-latomic"
> +endif

This looks good, but why don't we already see it with other
architectures for which atomic intrinsics are in libatomic? SPARC,
i386 32-bit, and also several other 32-bit architectures have 64-bit
atomic intrinsics in libatomic.

If you can reproduce the issue with another architecture (or an
already supported Coldfire), then you can send this patch
separately. From a quick look, I couldn't identify an autobuilder
failure.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 09/11] package/nginx: add m68k ColdFire TLS support

[Thomas Petazzoni via buildroot]

On Fri, Apr 24, 2026 at 03:23:24PM +0200, Jean-Michel Hautbois wrote:
> On m68k ColdFire, nginx with OpenSSL requires reduced optimization
> (-O1) and -fno-strict-aliasing to avoid aliasing violations in the
> OpenSSL/nginx interaction that cause segfaults in HTTPS handling.
> 
> Also enforce strict alignment (-mstrict-align) and explicitly link
> against the system crypto libraries including libatomic.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> ---
>  package/nginx/nginx.mk | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/package/nginx/nginx.mk b/package/nginx/nginx.mk
> index 41490caee2..35d53c3ec1 100644
> --- a/package/nginx/nginx.mk
> +++ b/package/nginx/nginx.mk
> @@ -87,6 +87,12 @@ else
>  NGINX_CONF_OPTS += --without-pcre
>  endif
>  
> +ifeq ($(BR2_m68k_cf),y)
> +NGINX_CFLAGS += -O1 -fno-strict-aliasing -mstrict-align
> +NGINX_CONF_ENV += LIBS="-lssl -lcrypto -lz -ldl -lpcre"
> +NGINX_CONF_OPTS += --with-ld-opt="-L$(STAGING_DIR)/usr/lib -lssl -lcrypto -lpcre2-8 -latomic -lz -ldl -lpthread"

This is clearly very, very hacky, and will not fly. Yes, it probably
solves your immediate problem, but if we were solving all problems
this way, Buildroot would be just a pile of hacks (which hopefully it
isn't at the moment!).

All the library stuff should not be needed. For the -O1, is it to
workaround a gcc bug? Was it reported upstream?

The strict aliasing stuff, why is it related to building on Coldfire?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 11/11] package/libglib2: add m68k ColdFire support

[Thomas Petazzoni via buildroot]

Hello,

On Fri, Apr 24, 2026 at 03:23:26PM +0200, Jean-Michel Hautbois wrote:
> On m68k ColdFire, libgio exceeds the default 16-bit GOT entry limit
> (8192 entries). Add -mxgot to use 32-bit GOT offsets.

Why isn't this already happening for existing Coldfire configurations?

> Also enable b_staticpic=true to allow linking static internal
> libraries (girepository-internals) into shared libraries
> (libgirepository), which requires position-independent code.

Why is this Coldfire specific?

> Disable sysprof profiling support which is not useful on embedded
> targets and adds unnecessary build complexity.

This should definitely be done as a separate patch, and even is
something you can send separately from the Coldfire series so that we
can merge it right away.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 10/11] package/mawk: create awk symlink on install

[Thomas Petazzoni via buildroot]

Hello Jean-Michel,

On Fri, Apr 24, 2026 at 03:23:25PM +0200, Jean-Michel Hautbois wrote:
> Many scripts and Makefiles expect 'awk' to be available in PATH.
> When mawk is the only awk implementation installed, create a symlink
> from awk to mawk so that these scripts work without modification.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>

Thanks for this patch! First of all, it could really be sent
separately from this series, as it is totally independent from the
Coldfire work. This would allow us to identify it as being
independent, and merge it independently (faster!) than the rest of the
Coldfire work that is more complicated.

> +define MAWK_CREATE_SYMLINK
> +	ln -sf mawk $(TARGET_DIR)/usr/bin/awk
> +endef
> +
> +MAWK_POST_INSTALL_TARGET_HOOKS += MAWK_CREATE_SYMLINK

This is good, but you forgot to account for the case where mawk may
not be the only awk implementation selected.

So you need to add:

   $(if $(BR2_PACKAGE_MAWK),mawk) \

to BUSYBOX_DEPENDENCIES in busybox.mk (you'll see a long list of such
dependencies). This ensures that full blown implementations are
installed *before* Busybox, and then when we install Busybox, we are
careful to not overwrite the already installed tools.

Then, you also need to avoid the conflict between gawk and mawk. After
discussing with other maintainers, it seems like our preference is to
have mawk win over gawk, so you should add:

ifeq ($(BR2_PACKAGE_GAWK),y)
MAWK_DEPENDENCIES += gawk
endif

This way, we will be sure that gawk gets built before mawk, ensuring
that mawk wins.

Could you look into this?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 11/11] package/libglib2: add m68k ColdFire support

[Jean-Michel Hautbois]

Hi Thomas,

Le 29/05/2026 à 15:44, Thomas Petazzoni via buildroot a écrit :
> Hello,
> 
> On Fri, Apr 24, 2026 at 03:23:26PM +0200, Jean-Michel Hautbois wrote:
>> On m68k ColdFire, libgio exceeds the default 16-bit GOT entry limit
>> (8192 entries). Add -mxgot to use 32-bit GOT offsets.
> 
> Why isn't this already happening for existing Coldfire configurations?
> 

-mxgot is required once libgio's GOT exceeds the 16-bit offset window 
(8192 entries).
It is not tied to a particular ColdFire core but to building a large 
enough shared library.

The only ColdFire currently supported, the 5208, is a no-MMU (FLAT) 
target that is not built with the full shared libgio that overflows the 
GOT, so the limit was never hit before AFAICT.

The MCF5441x is an MMU core built with shared libraries and the complete 
gio, which reaches it.

>> Also enable b_staticpic=true to allow linking static internal
>> libraries (girepository-internals) into shared libraries
>> (libgirepository), which requires position-independent code.
> 
> Why is this Coldfire specific?
> 

You are right, it should not be done here !

The real cause is the ColdFire V2/V3 cores (ISA_A/ISA_A+, e.g. the 
5208): they have no 32-bit PC-relative branch, so a -fPIC function whose 
body exceeds the 16-bit branch range cannot be assembled, see:

"Tried to convert PC relative branch to absolute jump", GCC PR 101971, 
closed as invalid for this reason.

That is why b_staticpic was disabled for the whole ColdFire family in
commit e70fefa3b8 back when the 5208 was the only ColdFire supported.

The V4/V4e cores (ISA_B/ISA_C), including the MCF5441x, gained the 
32-bit bra.l/bsr.l and build PIC code fine.

I verified this with both gcc 14.3.0 and 15.2.0.
So rather than overriding b_staticpic in libglib2, I propose to drop 
this hunk and instead restrict the workaround in pkg-meson.mk to 
BR2_m68k_cf5208, which lets newer ColdFire cores keep b_staticpic 
enabled (as girepository-internals needs).

That would be a separate patch in v2.

>> Disable sysprof profiling support which is not useful on embedded
>> targets and adds unnecessary build complexity.
> 
> This should definitely be done as a separate patch, and even is
> something you can send separately from the Coldfire series so that we
> can merge it right away.
> 

Indeed. I will split it into a standalone patch.

Thanks !
JM

> Thanks!
> 
> Thomas

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 02/11] package/gcc: force --with-arch=cf on m68k MCF5441x

[Jean-Michel Hautbois]

Hi Thomas,

Le 29/05/2026 à 12:52, Thomas Petazzoni a écrit :
> Hello Jean-Michel,
> 
> Thanks for this work.
> 
> On Fri, Apr 24, 2026 at 03:23:17PM +0200, Jean-Michel Hautbois wrote:
>> On m68k ColdFire V4e (MCF5441x) with BR2_USE_MMU selected, the
>> host-gcc build fails during the multilib pass because the compiler
>> cannot disambiguate between m68k and cf variants. It needs to be
>> configured explicitly with --with-arch=cf.
> 
> I'm rather confused by "cannot disambiguate between m68k and cf
> variants", isn't MCF5441x *only* a Coldfire processor?

You are right, that wording is poor and I will fix it in v2.

MCF5441x is indeed only a ColdFire (V4e) core.
The real reason --with-arch=cf is needed is in gcc/config.gcc.

The gcc m68k backend serves both the 680x0 family (arch "m68k") and the
ColdFire family (arch "cf") from one tree, with a shared multilib 
generator (gcc/config/m68k/t-mlibs).

The trigger here is that BR2_m68k_cf5441x selects an MMU target, so the 
tuple is m68k-*-linux* rather than the m68k-*-uclinux* used by the 
existing 5208. In the m68k-*-linux* case, config.gcc does:

     with_arch=${with_arch:-m68k}

So, it defaults --with-arch to "m68k" (680x0) when none is given.

That pulls in config/m68k/t-m68k, which sets M68K_ARCH=m68k and 
restricts the multilib CPU set to non-ColdFire devices (CPU !~ "^mcf"). 
Buildroot passes --with-cpu=54418 (a ColdFire core) via 
R2_GCC_TARGET_CPU, so t-mlibs then trips its own sanity check:

     $(error Error default cpu '...' is not in multilib set '...')

because the default CPU is ColdFire while the multilib set was narrowed
to 680x0.

Passing --with-arch=cf:
- overrides the m68k default
- selects config/m68k/t-cf
- the ColdFire default CPU is back in the set.

This is also why 5208 does not need it: as a no-MMU m68k-*-uclinux*
target it does not get the with_arch=m68k default, so its multilib set
spans all devices and the ColdFire default is accepted.

The change itself is unchanged. I will just rewrite that paragraph in
v2 to describe the m68k-*-linux* with_arch default instead of the
"disambiguate" phrasing, if you are ok with that ?

Thanks,
JM
PS: Sorry for the long detailed explanation, but I spent quite a bit of 
time on this one so I must be certain everything is really like I 
understood it :-)

> Otherwise I think the change is OK, and the description is very
> thorough and detailed.
> 
> Thomas

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 02/11] package/gcc: force --with-arch=cf on m68k MCF5441x

[Thomas Petazzoni via buildroot]

Hello Jean-Michel,

On Sat, May 30, 2026 at 09:31:53AM +0200, Jean-Michel Hautbois wrote:

> You are right, that wording is poor and I will fix it in v2.
> 
> MCF5441x is indeed only a ColdFire (V4e) core.
> The real reason --with-arch=cf is needed is in gcc/config.gcc.
> 
> The gcc m68k backend serves both the 680x0 family (arch "m68k") and the
> ColdFire family (arch "cf") from one tree, with a shared multilib generator
> (gcc/config/m68k/t-mlibs).
> 
> The trigger here is that BR2_m68k_cf5441x selects an MMU target, so the
> tuple is m68k-*-linux* rather than the m68k-*-uclinux* used by the existing
> 5208. In the m68k-*-linux* case, config.gcc does:
> 
>     with_arch=${with_arch:-m68k}
> 
> So, it defaults --with-arch to "m68k" (680x0) when none is given.
> 
> That pulls in config/m68k/t-m68k, which sets M68K_ARCH=m68k and restricts
> the multilib CPU set to non-ColdFire devices (CPU !~ "^mcf"). Buildroot
> passes --with-cpu=54418 (a ColdFire core) via R2_GCC_TARGET_CPU, so t-mlibs
> then trips its own sanity check:
> 
>     $(error Error default cpu '...' is not in multilib set '...')
> 
> because the default CPU is ColdFire while the multilib set was narrowed
> to 680x0.
> 
> Passing --with-arch=cf:
> - overrides the m68k default
> - selects config/m68k/t-cf
> - the ColdFire default CPU is back in the set.
> 
> This is also why 5208 does not need it: as a no-MMU m68k-*-uclinux*
> target it does not get the with_arch=m68k default, so its multilib set
> spans all devices and the ColdFire default is accepted.
> 
> The change itself is unchanged. I will just rewrite that paragraph in
> v2 to describe the m68k-*-linux* with_arch default instead of the
> "disambiguate" phrasing, if you are ok with that ?

Thanks for the detailed explanation, makes sense!

> PS: Sorry for the long detailed explanation, but I spent quite a bit of time
> on this one so I must be certain everything is really like I understood it
> :-)

Long detailed explanations are very very good, no need to apologize!

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 10/11] package/mawk: create awk symlink on install

[Arnout Vandecappelle via buildroot]

On 29/05/2026 16:00, Thomas Petazzoni via buildroot wrote:
> Then, you also need to avoid the conflict between gawk and mawk. After
> discussing with other maintainers, it seems like our preference is to
> have mawk win over gawk, so you should add:
> 
> ifeq ($(BR2_PACKAGE_GAWK),y)
> MAWK_DEPENDENCIES += gawk
> endif
> 
> This way, we will be sure that gawk gets built before mawk, ensuring
> that mawk wins.

  When discussing this I forgot that it doesn't actually work like that. What we 
have to do is to build gawk _after_ mawk, and make sure that gawk doesn't 
install the awk -> gawk symlink if there is already an awk installed. That is 
what busybox does.

  It has to be that way because the final target dir is not populated in 
dependency order, but in alphabetical order. It happens to work because mawk 
comes later than gawk so it wins, but we shouldn't rely on that.

  Regards,
  Arnout
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 10/11] package/mawk: create awk symlink on install

[Jean-Michel Hautbois]

Hi Arnout,

Le 30/05/2026 à 17:52, Arnout Vandecappelle via buildroot a écrit :
> 
> 
> On 29/05/2026 16:00, Thomas Petazzoni via buildroot wrote:
>> Then, you also need to avoid the conflict between gawk and mawk. After
>> discussing with other maintainers, it seems like our preference is to
>> have mawk win over gawk, so you should add:
>>
>> ifeq ($(BR2_PACKAGE_GAWK),y)
>> MAWK_DEPENDENCIES += gawk
>> endif
>>
>> This way, we will be sure that gawk gets built before mawk, ensuring
>> that mawk wins.
> 
>   When discussing this I forgot that it doesn't actually work like that. 
> What we have to do is to build gawk _after_ mawk, and make sure that 
> gawk doesn't install the awk -> gawk symlink if there is already an awk 
> installed. That is what busybox does.
> 
>   It has to be that way because the final target dir is not populated in 
> dependency order, but in alphabetical order. It happens to work because 
> mawk comes later than gawk so it wins, but we shouldn't rely on that.
> 

Thanks for the correction, that makes sense. Relying on the alphabetical 
install order is too fragile.

I will follow the busybox model instead: build gawk after mawk and make
gawk skip the 'awk' symlink when one is already installed, while keeping
mawk in BUSYBOX_DEPENDENCIES so BusyBox does not overwrite it either.

As this is independent of the Coldfire series, I will send it as a
separate, dedicated patch.

Thanks !
JM

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 0/8] Add ColdFire MCF5441x (m68k) support

[Jean-Michel Hautbois]

This series adds support for the NXP ColdFire MCF5441x family (m68k/cf:
MMU, V4e core, no hardware FPU, no atomic builtins) on top of uClibc-ng.

v2 is smaller and better justified after the v1 review (thanks Thomas
and Baruch). The per-patch changelogs are under each patch.

Main changes since v1:
 - Dropped libopenssl, ntp and the nginx block: no real defect, the
   existing logic already handles ColdFire.
 - Makefile.in: keep only -mlong-jump-table-offsets; the scheduler
   flags were dropped (they triggered the dropbear ICE).
 - New pkg-meson.mk patch: restrict the b_staticpic workaround to the
   5208 (GCC PR 101971), instead of the whole ColdFire family.
 - gcc/gmp/gdb: commit messages reworded to the real root cause.
 - libglib2 reduced to the ColdFire build fixes (-mxgot and static
   libstdc++/libgcc).

Two independent patches were split out of v1 and sent separately
(mawk awk symlink, libglib2 host sysprof).

Build-tested from scratch for cf5441x (V4e, uClibc-ng, gcc 14.3.0) and
run on MCF54418 hardware. All changes are guarded by BR2_m68k_cf, so no
impact on other m68k variants or architectures.

Jean-Michel Hautbois (8):
  arch/Config.in.m68k: add ColdFire MCF5441x support
  package/pkg-meson.mk: restrict ColdFire b_staticpic workaround to 5208
  package/gcc: force --with-arch=cf on m68k MCF5441x
  package/Makefile.in: use 32-bit jump table offsets on m68k ColdFire
  package/gmp: disable C++ bindings on m68k ColdFire
  package/gdb: link libstdc++ and libgcc statically on m68k ColdFire
  package/dropbear: disable ML-KEM768 on m68k
  package/libglib2: add m68k ColdFire support

 arch/Config.in.m68k          |  7 +++++++
 package/Makefile.in          |  2 ++
 package/dropbear/dropbear.mk |  7 +++++++
 package/gcc/gcc.mk           |  4 ++++
 package/gdb/gdb.mk           |  7 +++++++
 package/gmp/gmp.mk           |  7 ++++++-
 package/libglib2/libglib2.mk | 15 +++++++++++++++
 package/pkg-meson.mk         |  2 +-
 toolchain/Config.in          | 10 ++++++++++
 9 files changed, 59 insertions(+), 2 deletions(-)

-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 1/8] arch/Config.in.m68k: add ColdFire MCF5441x support

[Jean-Michel Hautbois]

Add the MCF5441x (54418) ColdFire V4e variant to the m68k architecture
menu. The 5441x selects BR2_m68k_cf, BR2_USE_MMU (V4e has an MMU, unlike
the 5208) and BR2_SOFT_FLOAT (no hardware FPU). The GCC target CPU is
set to 54418.

qemu-system-m68k does not emulate the 5441x family, so no qemu
defconfig is added; the existing qemu_m68k_mcf5208_defconfig and
qemu_m68k_q800_defconfig are not affected.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - No change since v1.

 arch/Config.in.m68k | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/Config.in.m68k b/arch/Config.in.m68k
index 235cafacf5..b281f43a30 100644
--- a/arch/Config.in.m68k
+++ b/arch/Config.in.m68k
@@ -38,12 +38,19 @@ config BR2_m68k_cf5208
 	select BR2_m68k_cf
 	select BR2_SOFT_FLOAT
 
+config BR2_m68k_cf5441x
+	bool "5441x"
+	select BR2_m68k_cf
+	select BR2_USE_MMU
+	select BR2_SOFT_FLOAT
+
 endchoice
 
 config BR2_GCC_TARGET_CPU
 	default "68030"		if BR2_m68k_68030
 	default "68040"		if BR2_m68k_68040
 	default "5208"		if BR2_m68k_cf5208
+	default "54418"		if BR2_m68k_cf5441x
 
 config BR2_READELF_ARCH_NAME
 	default "MC68000"
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 2/8] package/pkg-meson.mk: restrict ColdFire b_staticpic workaround to 5208

[Jean-Michel Hautbois]

b_staticpic was disabled for the whole ColdFire family in commit
e70fefa3b89d ("package/pkg-meson.mk: disable staticpic on Coldfire")
to work around a build failure: on ColdFire a -fPIC function whose body
exceeds the 16-bit PC-relative branch range cannot be assembled. The
only ColdFire core supported at the time (5208, a V2 / ISA_A core) has
no 32-bit PC-relative branch, so the assembler cannot widen the branch
and cannot fall back to an absolute jump under -fPIC ("Tried to convert
PC relative branch to absolute jump", see GCC PR 101971, closed as
invalid for exactly this reason).

This limitation only affects the ColdFire V2/V3 cores (ISA_A / ISA_A+).
The V4 and V4e cores (ISA_B / ISA_C, such as the MCF5441x) gained the
32-bit bra.l / bsr.l instructions and build position-independent code
without any issue, as verified with both gcc 14.3.0 and gcc 15.2.0.

Restrict the workaround to BR2_m68k_cf5208 so that newer ColdFire cores
keep b_staticpic enabled, which is required to link static internal
libraries into shared libraries (for example girepository-internals
into libgirepository in libglib2).

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - New patch in v2: replaces the per-package b_staticpic override
   that was in the v1 libglib2 patch, restricted to the 5208
   (GCC PR 101971) instead of the whole ColdFire family.

 package/pkg-meson.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index f2efbae2eb..a8400db974 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -164,7 +164,7 @@ define $(2)_CONFIGURE_CMDS
 		--buildtype=$(if $(BR2_ENABLE_RUNTIME_DEBUG),debug,release) \
 		--cross-file=$$($$(PKG)_SRCDIR)/buildroot-build/cross-compilation.conf \
 		-Db_pie=false \
-		-Db_staticpic=$(if $(BR2_m68k_cf),false,true) \
+		-Db_staticpic=$(if $(BR2_m68k_cf5208),false,true) \
 		-Dstrip=false \
 		-Dbuild.pkg_config_path=$$(HOST_DIR)/lib/pkgconfig \
 		-Dbuild.cmake_prefix_path=$$(HOST_DIR)/lib/cmake \
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 3/8] package/gcc: force --with-arch=cf on m68k MCF5441x

[Jean-Michel Hautbois]

The MCF5441x is a ColdFire V4e core, and BR2_m68k_cf5441x selects an
MMU target, so the toolchain tuple is m68k-buildroot-linux-uclibc.
For m68k-*-linux* targets, gcc/config.gcc defaults --with-arch to
"m68k" (the 680x0 family) when none is given. That default selects
config/m68k/t-m68k, which restricts the multilib CPU set to
non-ColdFire devices.

Buildroot passes --with-cpu=54418 (a ColdFire core) via
BR2_GCC_TARGET_CPU, so the t-mlibs default-cpu sanity check then fails
because the default CPU is not in the (680x0-only) multilib set, which
aborts the host-gcc build. Passing --with-arch=cf overrides the
default, selects config/m68k/t-cf and puts the ColdFire CPU back into
the multilib set.

The existing no-MMU 5208 ColdFire (m68k-*-uclinux*) does not need this:
that target case in config.gcc does not default --with-arch to m68k,
so its multilib set already spans ColdFire devices.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - Reword the commit message to the real root cause; no code
   change since v1.

 package/gcc/gcc.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index ea96286c32..270a0638d9 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -220,6 +220,10 @@ endif
 ifneq ($(GCC_TARGET_ARCH),)
 HOST_GCC_COMMON_CONF_OPTS += --with-arch="$(GCC_TARGET_ARCH)"
 endif
+
+ifeq ($(BR2_m68k_cf5441x),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-arch=cf
+endif
 ifneq ($(GCC_TARGET_ABI),)
 HOST_GCC_COMMON_CONF_OPTS += --with-abi="$(GCC_TARGET_ABI)"
 endif
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 4/8] package/Makefile.in: use 32-bit jump table offsets on m68k ColdFire

[Jean-Michel Hautbois]

On m68k ColdFire, switch statement jump tables use signed 16-bit .word
offsets by default. Large functions (for example in pcre2 and
nftables) overflow this, causing an assembler error:

  Error: Adjusted signed .word overflows: `switch'-statement too large

This affects every ColdFire core: the 16-bit jump table offset is
independent of the core ISA (verified to fail identically on the V2
5208 and the V4e MCF5441x). Add -mlong-jump-table-offsets globally for
BR2_m68k_cf, alongside the existing -fno-dwarf2-cfi-asm. The flag is
harmless when not needed and the overflow is not predictable from the
package list, so a global setting is preferable to a per-package one.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - Keep only -mlong-jump-table-offsets; drop the
   -fno-schedule-insns/-fno-schedule-insns2 flags, which had no
   upstream backing and triggered the dropbear ML-KEM ICE.

 package/Makefile.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/Makefile.in b/package/Makefile.in
index 5ebb5f9ba8..7017649c09 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -211,6 +211,8 @@ TARGET_FCFLAGS = $(TARGET_ABI) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)
 ifeq ($(BR2_m68k_cf),y)
 TARGET_CFLAGS += -fno-dwarf2-cfi-asm
 TARGET_CXXFLAGS += -fno-dwarf2-cfi-asm
+TARGET_CFLAGS += -mlong-jump-table-offsets
+TARGET_CXXFLAGS += -mlong-jump-table-offsets
 endif
 
 ifeq ($(BR2_BINFMT_FLAT),y)
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 5/8] package/gmp: disable C++ bindings on m68k ColdFire

[Jean-Michel Hautbois]

ColdFire has no hardware atomic instructions, so the compiler lowers
atomic operations (such as the libstdc++ reference-count helpers) to
out-of-line __sync_* calls. Those helpers are provided by libgcc, but
only with hidden ELF visibility. libstdc++ is built referencing them
and ends up with undefined, default-visibility __sync_*_4 dynamic
symbols. Building gmp's C++ bindings (libgmpxx.so) against libstdc++
then fails to link, because the only definition is hidden in libgcc
and cannot satisfy the cross-DSO reference.

Disable the C++ bindings on m68k ColdFire. The C library (libgmp.so)
is unaffected. The same underlying limitation is handled for gdb in a
separate patch.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - Reword the commit message and add an explanatory comment;
   approach unchanged since v1.

 package/gmp/gmp.mk | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/package/gmp/gmp.mk b/package/gmp/gmp.mk
index 07aa4aefdf..9f85073556 100644
--- a/package/gmp/gmp.mk
+++ b/package/gmp/gmp.mk
@@ -31,7 +31,12 @@ ifeq ($(BR2_riscv):$(BR2_RISCV_ISA_RVM),y:)
 GMP_CONF_OPTS += --disable-assembly
 endif
 
-ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
+# On m68k ColdFire (no hardware atomics), libstdc++ references the
+# libgcc __sync_* helpers, which are hidden, so building the C++
+# bindings (libgmpxx) fails to link. Disable them; see also gdb.
+ifeq ($(BR2_m68k_cf),y)
+GMP_CONF_OPTS += --disable-cxx
+else ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
 GMP_CONF_OPTS += --enable-cxx
 else
 GMP_CONF_OPTS += --disable-cxx
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 6/8] package/gdb: link libstdc++ and libgcc statically on m68k ColdFire

[Jean-Michel Hautbois]

ColdFire has no hardware atomic instructions, so libstdc++ references
the libgcc __sync_* helpers, which are exported with hidden ELF
visibility. Linking gdb (a C++ program) dynamically against libstdc++
fails because those hidden symbols cannot satisfy the cross-DSO
references. The same root cause is addressed for gmp in a separate
patch.

Link libstdc++ and libgcc statically to avoid the hidden-symbol
references. The flags are appended to TARGET_LDFLAGS rather than
overwriting LDFLAGS.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - Reword the commit message; fold the flags into GDB_LDFLAGS
   (appended to TARGET_LDFLAGS) instead of overwriting LDFLAGS.

 package/gdb/gdb.mk | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/package/gdb/gdb.mk b/package/gdb/gdb.mk
index 2a2fdb260d..271ab9d942 100644
--- a/package/gdb/gdb.mk
+++ b/package/gdb/gdb.mk
@@ -121,6 +121,13 @@ GDB_LDFLAGS = $(TARGET_LDFLAGS)
 ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
 GDB_LDFLAGS += -latomic
 endif
+# On m68k ColdFire (no hardware atomics), libstdc++ references the
+# hidden libgcc __sync_* helpers, so linking gdb dynamically against
+# libstdc++ fails. Link libstdc++ and libgcc statically instead; see
+# also the gmp package.
+ifeq ($(BR2_m68k_cf),y)
+GDB_LDFLAGS += -static-libstdc++ -static-libgcc
+endif
 GDB_CONF_ENV += \
 	LDFLAGS="$(GDB_LDFLAGS)"
 
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 7/8] package/dropbear: disable ML-KEM768 on m68k

[Jean-Michel Hautbois]

ML-KEM768 post-quantum key exchange code (in the vendored header
src/libcrux_mlkem768_sha3.h) triggers a GCC internal compiler error
(ICE) in cselib_record_set during the postreload CSE pass when
compiled at -O2 on m68k. Reproduced with the Buildroot default
GCC 14.3.0 on ColdFire (cselib.cc:2727); GCC 15.2.0 hits the same ICE
(cselib.cc:2869).

The bug is tracked upstream as GCC PR rtl-optimization/125078:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125078

A new BR2_TOOLCHAIN_HAS_GCC_BUG_125078 helper symbol is added in
toolchain/Config.in following the convention used for other
known-broken toolchains, and the dropbear build hook is gated on it so
the workaround is removed automatically once GCC ships a fix. It is
enabled for all m68k, conservatively, as the ICE is present in the
default GCC 14.3.0.

Standard key exchange algorithms remain available.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - Gate on the new BR2_TOOLCHAIN_HAS_GCC_BUG_125078 (added in
   toolchain/Config.in), as requested by Baruch on v1.

 package/dropbear/dropbear.mk |  7 +++++++
 toolchain/Config.in          | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/package/dropbear/dropbear.mk b/package/dropbear/dropbear.mk
index a7de8432af..f40520d4d8 100644
--- a/package/dropbear/dropbear.mk
+++ b/package/dropbear/dropbear.mk
@@ -62,6 +62,13 @@ endef
 DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_SVR_PASSWORD_AUTH
 endif
 
+ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_125078),y)
+define DROPBEAR_DISABLE_MLKEM
+	echo '#define DROPBEAR_MLKEM768 0'               >> $(@D)/localoptions.h
+endef
+DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_DISABLE_MLKEM
+endif
+
 ifeq ($(BR2_PACKAGE_DROPBEAR_LEGACY_CRYPTO),y)
 define DROPBEAR_ENABLE_LEGACY_CRYPTO
 	echo '#define DROPBEAR_3DES 1'                  >> $(@D)/localoptions.h
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 910cd103dc..3bb7ab269d 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -246,6 +246,16 @@ config BR2_TOOLCHAIN_HAS_GCC_BUG_111001
 		   BR2_OPTIMIZE_2 || \
 		   BR2_OPTIMIZE_3
 
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125078
+# ICE in cselib_record_set during the postreload CSE pass when
+# compiling ML-KEM code at -O2 on m68k (cselib.cc:2727 with gcc
+# 14.3.0, cselib.cc:2869 with gcc 15.2.0). Reproduced at -O2 with the
+# Buildroot default gcc 14.3.0 on ColdFire. Enabled for all m68k
+# conservatively, as the bug is present in the default gcc 14.3.0.
+config BR2_TOOLCHAIN_HAS_GCC_BUG_125078
+	bool
+	default y if BR2_m68k
+
 config BR2_TOOLCHAIN_HAS_NATIVE_RPC
 	bool
 
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v2 8/8] package/libglib2: add m68k ColdFire support

[Jean-Michel Hautbois]

On m68k ColdFire, two issues prevent libglib2 from building.

First, libgio's GOT exceeds the default 16-bit GOT entry limit (8192
entries: its .got holds ~12800 entries), so the 16-bit R_68K_GOT16O
relocation overflows. Add -mxgot to use 32-bit GOT offsets.

Second, glib optionally enables a C++ language (add_languages()), so
meson probes some dependencies (such as iconv) using the C++ compiler.
On ColdFire that link pulls libstdc++, which references the __sync_*
helpers that libgcc only provides as hidden symbols, so the link fails
with "hidden symbol ... referenced by DSO" and the probe (and thus the
whole configure step) fails. Link libstdc++ and libgcc statically to
keep these probes working. This is the same root cause addressed for
gmp and gdb earlier in this series.

Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
---
Changes since v1:
 - Drop the b_staticpic hunk (moved to pkg-meson.mk) and the
   sysprof hunk (sent separately). Add -static-libstdc++ and
   -static-libgcc for glib's C++ iconv probe; keep -mxgot.

 package/libglib2/libglib2.mk | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/package/libglib2/libglib2.mk b/package/libglib2/libglib2.mk
index cae8a85a28..77a7172392 100644
--- a/package/libglib2/libglib2.mk
+++ b/package/libglib2/libglib2.mk
@@ -55,6 +55,21 @@ endif
 # containing ${libdir} in gio-2.0.pc. Indeed, a value depending on
 # ${libdir} would be prefixed by the sysroot by pkg-config, causing a
 # bogus installation path once combined with $(DESTDIR).
+# libgio's GOT exceeds the 16-bit offset window on m68k ColdFire
+# (relocation truncated to fit: R_68K_GOT16O); use 32-bit GOT offsets.
+#
+# glib optionally enables a C++ language (add_languages()), so meson
+# probes some dependencies (such as iconv) with the C++ compiler. On
+# ColdFire that link pulls libstdc++, which references the __sync_*
+# helpers that libgcc only provides as hidden symbols, so the link
+# fails ("hidden symbol ... referenced by DSO"). Link libstdc++ and
+# libgcc statically to keep these probes (and any C++ object) working.
+# See the gmp and gdb commits for the same root cause.
+ifeq ($(BR2_m68k_cf),y)
+LIBGLIB2_CFLAGS += -mxgot
+LIBGLIB2_LDFLAGS += -static-libstdc++ -static-libgcc
+endif
+
 LIBGLIB2_CONF_OPTS = \
 	-Dglib_debug=disabled \
 	-Dlibelf=disabled \
-- 
2.39.5

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot