Skip to content

Backport modern-host build fixes (gcc 16, MPFR, CMake 4) to 2025.02-op-build#40

Closed
runlevel5 wants to merge 6 commits into
open-power:2025.02-op-buildfrom
runlevel5:2025.02-op-build-host-gcc16
Closed

Backport modern-host build fixes (gcc 16, MPFR, CMake 4) to 2025.02-op-build#40
runlevel5 wants to merge 6 commits into
open-power:2025.02-op-buildfrom
runlevel5:2025.02-op-build-host-gcc16

Conversation

@runlevel5
Copy link
Copy Markdown

@runlevel5 runlevel5 commented Jun 3, 2026 •
edited
Loading

Building op-build natively on a modern host (e.g. Fedora 44: gcc 16, binutils 2.46, MPFR 4.2, CMake 4) fails across several independent dimensions, because the 2025.02 LTS branch predates these toolchain/library changes.

Commit Package Dimension / fix
package/gmp gmp 6.3.0 gcc-16 C23 — prototype in acinclude.m4 (GMP_PROG_CC_WORKS). Cherry-pick 31569bcc1b.
package/m4 m4 1.4.19 gcc-16 C23 — force -std=gnu17 for host-m4. Backport of 7a07a9d155.
package/gcc gcc 13.3.0 host gcc 16 — libcody char8_t / include-order. Patches from 10ccbe079c.
package/mpfr 4.1.1 → 4.2.2 host-lib shadowing — mpfr_acospi. Cherry-pick 6e54d5fb92.
package/dtc 1.7.2 -Werror — discarded-qualifiers. Patch from 3b52fe6f2e.
package/lzo 2.10 CMake 4 — cmake_minimum_required compat. Cherry-pick 223abaf98a.

Notes

WIP - still more packages needed to be back ported and verified on both Fedora 33 and 44

Testing

  • f33 toolbox (gcc 10.3): full blackbird build succeeds with the first three commits — no regression.
  • native Fedora 44 (gcc 16): with all six, the build clears the host toolchain and the gcc-16/CMake-4 host packages, but then hits the host-library shadowing cascade described above.

jolivain and others added 3 commits June 3, 2026 15:33
@jolivain @runlevel5
package/gmp: add patch to fix build with gcc-15
87b90f5 
When using host gcc 15, host-gmp fails at configure time with
error message:

    configure: error: could not find a working compiler, see config.log for details

The error is due to the macro GMP_PROG_CC_WORKS in the file
acinclude.m4 containing C-code declaring functions without declaring
its parameters. This construct is now an error in C23, which is the
new default in gcc 15. See:
https://gcc.gnu.org/gcc-15/porting_to.html#c23

This commit fixes the issue by adding a package patch from
upstream changesets, not yet published in a release.

Even if gcc 15 is not yet included in Buildroot, this commit also
sets _AUTORECONF = YES for the target package in order to have this
package already fixed.

Fixes:
https://autobuild.buildroot.org/results/623634fa7bbeceeb6d90b15ce0abb1b9b4b24045/

Tested-by: Brigham Campbell <me@brighamcampbell.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 31569bc)
@runlevel5
package/m4: fix build failure with host-gcc >= 15
fa1773b 
When compiling host-m4 1.4.19 with host gcc >= 15 (default on Fedora 42+
/ Ubuntu 25.10+), the build fails because gcc 15 changed its default C
standard from gnu17 to gnu23, which the gnulib copy bundled in m4 1.4.19
does not detect properly:

    gl_oset.h:275:40: error: expected identifier or '(' before 'int'

Force the previous default -std=gnu17 for the host-m4 build.

This is a backport of upstream commit 7a07a9d ("package/m4: fix build
failure with host-gcc 15"), applied unconditionally because the 2025.02
branch does not have the BR2_HOST_GCC_AT_LEAST_15 symbol used upstream;
-std=gnu17 is a no-op on gcc < 15 (the option exists since gcc 8).

Signed-off-by: Trung Le <8@tle.id.au>
@runlevel5
package/gcc: fix gcc-13 build with host gcc 16
64a4aa7 
Building gcc 13.3.0 with a host gcc 16 fails because gcc 16 defaults to a
newer C++ standard in which u8"" literals are char8_t, which libcody and
the gcc build system do not handle:

    libcody/buffer.cc:348:39: error: no matching function for call to
        'S2C(const char8_t [2])'

Backport the two upstream patches that fix this (from buildroot commit
10ccbe079c "package/gcc: fix gcc-13 build with host gcc 16", which carries
them in package/gcc/13.4.0/): a libcody fix to build under C++11..C++26,
and an include-order fix in gcc/system.h. Numbered 0006/0007 to sit after
the existing 13.3.0 patch series.

Signed-off-by: Trung Le <8@tle.id.au>
@runlevel5 runlevel5 mentioned this pull request Jun 3, 2026
Draft
codingWiz-rick and others added 3 commits June 3, 2026 22:59
@codingWiz-rick @runlevel5
package/mpfr: bump version to 4.2.2
31b70bc 
Update MPFR from 4.1.1 to 4.2.2.

Release notes:
https://www.mpfr.org/mpfr-4.2.2/

Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6e54d5fb928eeb7557bbec1e5ce72457ff1bff0b)
@Tropicao @runlevel5
package/dtc: fix host build with glibc 2.43
a08c926 
When trying to build host-dtc on a host with glibc 2.43, the build fails
on the following error:

  libfdt/fdt_overlay.c: In function ‘overlay_fixup_phandle’:
  libfdt/fdt_overlay.c:424:21: error: assignment discards ‘const’
  qualifier from pointer target type [-Werror=discarded-qualifiers]
    424 |                 sep = memchr(fixup_str, ':', fixup_len);
        |                     ^
  libfdt/fdt_overlay.c:434:21: error: assignment discards ‘const’
  qualifier from pointer target type [-Werror=discarded-qualifiers]
    434 |                 sep = memchr(name, ':', fixup_len);
        |                     ^
  fdtput.c: In function ‘create_node’:
  fdtput.c:235:11: error: assignment discards ‘const’ qualifier from
  pointer target type [-Werror=discarded-qualifiers]
    235 |         p = strrchr(node_name, '/');
        |           ^
  cc1: all warnings being treated as errors
  make[2]: *** [Makefile:359: fdtput.o] Error 1
  make[2]: *** Waiting for unfinished jobs....
  cc1: all warnings being treated as errors
  make[2]: *** [Makefile:359: libfdt/fdt_overlay.o] Error 1
  make[1]: *** [package/pkg-generic.mk:273:
  /home/alexis/src/buildroot/dtc/build/host-dtc-1.7.2/.stamp_built] Error 2
  make: *** [Makefile:83: _all] Error 2

The issue can be reproduced on master with this minimal defconfig on a
host having glibc 2.43:

  BR2_x86_64=y
  BR2_TOOLCHAIN_EXTERNAL=y
  BR2_PACKAGE_QORIQ_MC_UTILS=y

(QORIQ_MC_UTILS will pull HOST_DTC)

This error is due to some functions prototype update in glibc 2.43 for
ISO C23 (see [1], point 3 in the NEWS list). The corresponding fix has
already been integrated upstream, but it has not been released since
then.

Bring the corresponding upstream patch to allow host-dtc to build on
affected hosts.

[1] https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html

Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3b52fe6f2e0feb72e745991a1ad4645ffdc55713)
@florolf @runlevel5
package/lzo: fix CMake 4.0 compatibility
f7fcf20 
Add a patch to fix lzo builds with CMake 4.0.

Fixes:
 https://autobuild.buildroot.org/results/8d9/8d9cc53d68d93432e6a7bddad0ed3fdaed913da6 (target)
 https://autobuild.buildroot.org/results/aba/aba68e0889b66300f87706e15ff34899d3e1e97f (host)
 (and many more)

Signed-off-by: Florian Larysch <fl@n621.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 223abaf)
@runlevel5 runlevel5 changed the title Backport host gcc 15/16 build fixes (m4, gmp, gcc) to 2025.02-op-build Backport modern-host build fixes (gcc 16, MPFR, CMake 4) to 2025.02-op-build Jun 3, 2026
@runlevel5
Copy link
Copy Markdown
Author

runlevel5 commented Jun 3, 2026 •
edited
Loading

Closing: see updated description. The amount of backport from 2026.05 to 2025.02 is climbing fast. The best is to adopt 2026.05 or roll forward to 2025.02.x (plus some backports)

@runlevel5 runlevel5 closed this Jun 3, 2026
@rarbab
Copy link
Copy Markdown
Member

rarbab commented Jun 3, 2026

@runlevel5 Does the buildroot 2025.02.x branch contain all these backports?

@runlevel5
Copy link
Copy Markdown
Author

runlevel5 commented Jun 4, 2026 •
edited
Loading

Does the buildroot 2025.02.x branch contain all these backports?

@rarbab good news, the 2025.02.x does contain most, only mpfr needs to be backported, here is the commands to prepare the 2025.02.x-op-build branch for your consideration:

git remote add upstream https://github.com/buildroot/buildroot.git

# Fetch the 2025.02.x LTS maintenance branch, the existing fork branch, and master (for the mpfr fix)
git fetch upstream 2025.02.x master
git fetch origin 2025.02-op-build

# New branch off the LTS maintenance branch (gets m4 1.4.21, gcc 13.4.0, gmp/dtc fixes,
# openssl 3.5.6, ... for free — these are what the frozen 2025.02 *tag* lacked)
git checkout -b 2025.02.x-op-build upstream/2025.02.x

# Re-apply op-build's 3 local commits (currently carried on 2025.02-op-build = 2025.02 tag + these 3)
git cherry-pick c497ccb0f2 cb41ab85ad a872efdc28
#   c497ccb0f2  Separate target-building make targets from image-building make targets
#   cb41ab85ad  package/dropbear: Add separate configuration option for dropbear server
#   a872efdc28  package/petitboot: enable discovery of MTD devices

# Add the ONE fix the LTS branch still lacks: mpfr 4.1.1 -> 4.2.2
# (a native gcc-16 host build needs mpfr_acospi (MPFR 4.2) — cc1plus is loaded via the
#  build's LD_LIBRARY_PATH=host/usr/lib and otherwise fails with "undefined symbol: mpfr_acospi")
git cherry-pick -x 6e54d5fb92        # "package/mpfr: bump version to 4.2.2" (carries the new hash)

git push origin 2025.02.x-op-build

I have verified on both Fedora 33 and 44

EDIT: Here is my 2025-02.x-op-build branch https://github.com/runlevel5/buildroot/tree/2025.02.x-op-build for your reference

@runlevel5 runlevel5 deleted the 2025.02-op-build-host-gcc16 branch June 4, 2026 05:23
@rarbab
Copy link
Copy Markdown
Member

rarbab commented Jun 5, 2026

I just updated the 2025.02-op-build branch to the latest tagged release (2025.02.14) in 3fd3e2f. We'll need to update op-build's submodule commit accordingly.

Let's wait to see if the mpfr issue gets addressed upstream.

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@runlevel5 @rarbab @jolivain @codingWiz-rick @Tropicao @florolf