[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