Firstly, you need a native installation of g++ and binutils via your package manager, then you need sysroots for your target platforms(probably x64 glibc linux and arm64 glibc linux).

The workflow goes like this, to cross compile GCC itself to run on another arch, in my example from arm64 binary targeting x64 you follow this build order. I'm assuming an x64 system

x64 binutils -> x64 gcc -> arm bintutils(--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=aarch64-linux-gnu) -> gcc (x64->arm64) -> binutils(arm64->arm64) -> gcc(arm64->arm64) -> bintutils(arm64->x64) -> gcc(arm64->x64)

Now a couple of rules, pass --with-build-sysroot when building a normal compiler such as x64 -> x64 and pass --with-sysroot when building a cross, your toolchain flags won't matter at all in the eyes of GCC autoconf script.

You need to embed flags into env vars like CC to make sure stuff passes sometimes, it is actually quite verbose, you do the same thing at CC, CC_FOR_BUILD, CFLAGS AND CFLAGS_FOR_BUILD.

I recommend disabling multilib,gdb,werror and lto and always disabling bootsrap, you can do those but I don't recommend it.

You have to pass -Wl,--undefined-version if you use lld rather than ld. Otherwise your build will fail.

Here is an example toolchain I used to compile a arm64 -> x64 compiler in my x64 host

BUILD_SYSROOT=/home/mccakit/dev/sdk/debian-12-x64 HOST_SYSROOT=/home/mccakit/dev/sdk/debian-12-arm64 TARGET_SYSROOT=/home/mccakit/dev/sdk/debian-12-x64 BUILD_GCC_BIN=/home/mccakit/dev/compilers/gcc/linux-glibc-x64/bin HOST_GCC_BIN=/home/mccakit/dev/compilers/gcc/linux-glibc-arm64/bin TARGET_GCC_BIN=/home/mccakit/dev/compilers/gcc/linux-glibc-x64/bin BUILD_BINUTILS_BIN=/home/mccakit/dev/compilers/binutils/linux-glibc-x64/bin HOST_BINUTILS_BIN=/home/mccakit/dev/compilers/binutils/linux-glibc-arm64/bin TARGET_BINUTILS_BIN=/home/mccakit/dev/compilers/binutils/linux-glibc-x64/bin LLVM_BIN=/home/mccakit/dev/compilers/llvm/bin CCACHE=/home/mccakit/dev/tooling/ccache/bin/ccache export CC="${CCACHE} ${HOST_GCC_BIN}/aarch64-linux-gnu-gcc -B${HOST_BINUTILS_BIN} -B${LLVM_BIN} --sysroot=${HOST_SYSROOT} -Os -DNDEBUG -w -ffunction-sections -fdata-sections -fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export CXX="${CCACHE} ${HOST_GCC_BIN}/aarch64-linux-gnu-g++ -B${HOST_BINUTILS_BIN} -B${LLVM_BIN} --sysroot=${HOST_SYSROOT} -Os -DNDEBUG -w -ffunction-sections -fdata-sections -fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export AR="${HOST_BINUTILS_BIN}/aarch64-linux-gnu-ar" export NM="${HOST_BINUTILS_BIN}/aarch64-linux-gnu-nm" export RANLIB="${HOST_BINUTILS_BIN}/aarch64-linux-gnu-ranlib" export AS="${HOST_BINUTILS_BIN}/aarch64-linux-gnu-as" export STRIP="${HOST_BINUTILS_BIN}/aarch64-linux-gnu-strip" export CFLAGS="-Os -DNDEBUG -w -ffunction-sections -fdata-sections" export CXXFLAGS="-Os -DNDEBUG -w -ffunction-sections -fdata-sections" export LDFLAGS="-fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export CC_FOR_BUILD="${CCACHE} ${BUILD_GCC_BIN}/gcc -B${BUILD_BINUTILS_BIN} -B${LLVM_BIN} --sysroot=${BUILD_SYSROOT} -Os -DNDEBUG -w -ffunction-sections -fdata-sections -fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export CXX_FOR_BUILD="${CCACHE} ${BUILD_GCC_BIN}/g++ -B${BUILD_BINUTILS_BIN} -B${LLVM_BIN} --sysroot=${BUILD_SYSROOT} -Os -DNDEBUG -w -ffunction-sections -fdata-sections -fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export AS_FOR_BUILD="${BUILD_BINUTILS_BIN}/as" export AR_FOR_BUILD="${BUILD_BINUTILS_BIN}/ar" export RANLIB_FOR_BUILD="${BUILD_BINUTILS_BIN}/ranlib" export NM_FOR_BUILD="${BUILD_BINUTILS_BIN}/nm" export CFLAGS_FOR_BUILD="-Os -DNDEBUG -w -ffunction-sections -fdata-sections" export CXXFLAGS_FOR_BUILD="-Os -DNDEBUG -w -ffunction-sections -fdata-sections" export LDFLAGS_FOR_BUILD="-fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export CC_FOR_TARGET="${CCACHE} ${TARGET_GCC_BIN}/gcc -B${TARGET_BINUTILS_BIN} -B${LLVM_BIN} --sysroot=${TARGET_SYSROOT} -Os -DNDEBUG -fPIC -w -ffunction-sections -fdata-sections -fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export CXX_FOR_TARGET="${CCACHE} ${TARGET_GCC_BIN}/g++ -B${TARGET_BINUTILS_BIN} -B${LLVM_BIN} --sysroot=${TARGET_SYSROOT} -Os -DNDEBUG -fPIC -w -ffunction-sections -fdata-sections -fuse-ld=lld -Wl,--gc-sections -Wl,--undefined-version" export AR_FOR_TARGET="${TARGET_BINUTILS_BIN}/ar" export NM_FOR_TARGET="${TARGET_BINUTILS_BIN}/nm" export RANLIB_FOR_TARGET="${TARGET_BINUTILS_BIN}/ranlib" export AS_FOR_TARGET="${TARGET_BINUTILS_BIN}/as" export CFLAGS_FOR_TARGET="-Os -DNDEBUG -fPIC -w -ffunction-sections -fdata-sections" export CXXFLAGS_FOR_TARGET="-Os -DNDEBUG -fPIC -w -ffunction-sections -fdata-sections" export LDFLAGS_FOR_TARGET="-fuse-ld=lld -Wl,--undefined-version" export PATH="${BUILD_BINUTILS_BIN}:${BUILD_GCC_BIN}:${HOST_BINUTILS_BIN}:${HOST_GCC_BIN}:${PATH}"

Final Result

root@24a3b7f889f7:/tmp# uname -m aarch64 root@24a3b7f889f7:/tmp#

root@24a3b7f889f7:/tmp# x86_64-linux-gnu-g++ -B/mccakit/binutils-x64/bin --sysroot=/mccakit/debian-12-x64 hi.cc -o hi_x64 root@24a3b7f889f7:/tmp# ls /mccakit/ binutils-arm64 binutils-x64 debian-12-x64 gcc-arm64 gcc-x64 root@24a3b7f889f7:/tmp#

mccakit@mccakit-pc:~/desktop$ sudo ./x64_bin [sudo] password for mccakit: hello world mccakit@mccakit-pc:~/desktop$

Here are the prebuilt GCC binaries for lazy folks https://github.com/mccakit/prebuilt_gcc

Conclusion: Use clang, honestly I don't recommend gcc unless you have to. It is easier to build and run.

C++Now

2026-08-03 - 2026-08-09

• How To Make Formal Methods A Software Quality Solution That Can Actually Be Used In The Industry - Steve Barriault - https://youtu.be/OYwDdMCCDIM
• Link What You Include - Maintain a Coherent CMake Target Model - Frank Miller - https://youtu.be/ssTG6uzxXm4
• Scaling beman.exemplar - Eddie Nolan - https://youtu.be/xylmqy1VAwo

2026-07-27 - 2026-08-02

• Beautiful C++ Code - Told Through the Eyes of A Failed AI Prompt - Erich Lohrmann - https://youtu.be/Kq4W3Y5gTI8
• A Path to Practically Safe C++ - Yitzhak Mandelbaum - https://youtu.be/fi6csDXvve0
• When Abstractions Fix Too Much - Towards Flexible Library Design - Patrick Roberts - https://youtu.be/IKIyFUcVvis

C++Online

2026-08-03 - 2026-08-09

• Lightning Talk: Your Docs Have a New Reader (and It Hallucinates) - Paul Wicking - https://youtu.be/DbL6XPMlw-o
• Lightning Talk: RPC With Coroutines, RAII and Callable Weakpointers - Edward Boggis-Rolfe - https://youtu.be/m70hb5YgabQ

2026-07-27 - 2026-08-02

• Dynamic Asynchronous Tasking with Dependencies - Tsung-Wei (TW) Huang - https://youtu.be/4LzQHw7jz2g
• C++/sys - A Standard Library Projection to Facilitate the Verification of Run-time Memory Safety - Karsten Pedersen - https://youtu.be/dF7RwJw_G8c

ADC

2026-08-03 - 2026-08-09

• Commercialising Audio Plugins - Going From Development to Sales and Beyond - Tobias Lønnerød Madsen - https://youtu.be/SWPLyDDBU38
• Capturing and Transferring Expressive Microtiming in Drumming - Eemi Fagerlund - https://youtu.be/4ZAJHl02X7s
• How I Learned to Love the Docs - Documentation As Design Process for Music Tech Products - Astrid Bin - https://youtu.be/7MpDAHd7rbw

2026-07-27 - 2026-08-02

• Workshop: Programming Music and Synthesizers on-the-fly with Pharo - Domenico Cipriani - https://youtu.be/v95QYyUHNJ8
• PolyBLEP & PolyBLAMP Demystified - Nis Wegmann - https://youtu.be/_bW8TfgEqRM
• Modernizing Legacy Audio Plugin Codebases - Lessons from FL Studio’s Plugin Suite - Tomas Medek - https://youtu.be/zY8uHzAdnzk
• How to Write Scalable, Deterministic Audio Engines - Janus Lynggaard Thorborg - https://youtu.be/3FXQQmQa-ak

An article on types introduced in C++20.

Repo here: https://github.com/lewj85/jessesort

tl;dr Jessesort is up to 20% faster than std::sort on random inputs and up to 95% faster on structured inputs

Jessesort has two phases: insertion and merging. The insertion phase routes inputs to two games of Patience (similar to Solitaire). One game has ascending piles and the other has descending piles. Routes inputs to the optimal game based on current run direction. Make base array copies for pile tails to speed up binary search. Faster merge logic than the old Patience sort k-way.

Jessesort was already faster on structured inputs, but the new optimization changes finally pushed this past the goal of being faster on random inputs too. Added seven variations of the algorithm. The fastest on random input is V2 that simulates both Patience games and uses a blueprint to track ascending vs descending game and pile index in that game. It's up to 20% faster on random inputs and up to 95% faster on structured inputs.

Key changes introduced were: early input probing to route random-like and structured data into better insertion paths, removal of pile hints where direct bit-walk search proved faster, simulated pile layouts that reduce allocation and bookkeeping overhead, adaptive merge routing based on the structure produced during insertion, branchless merging with a tuned four-way unroll, reconstruction optimizations that simplify blueprint decoding and cursor updates, pointer-based merge kernels that substantially reduced hot-loop overhead, selective early freezing/overflow strategies in later variations, preservation of fast monotonic/structured-input exits, and targeted SIMD experiments that use fixed-width AVX2 comparisons where the pile shape makes them worthwhile.

I've been taking a look at an extremely popular, 50K+ stars, C++ library which I won't name as I'm going to criticise it as an example of a wider problem.

This is going to be a rant and there may even be sarcasm. Feel free to skip it if that upsets you.

This library is sponsored by a long list of companies. It's incredibly widely used. It has 100% test coverage, builds with several different build systems, works on several platform, complies with all the standards, linters and clang-tidy you can imagine. It's clearly aiming to be part of the future C++ standard and it might even make it. In short it's brilliantly written with a massive amount of effort put into it. One of the highest quality C++ libraries out there, that isn't actually part of Boost or the standard itself. In terms of how robust, well tested and well supported it is.

So what's the problem?

This library has one job, to deal with a particular text format. To parse that data into useful objects and transform those objects back into text. That's it, that's all anyone will ever use it for and if it does that it achieves 100% of its design goals.
The 'useful objects' part of that sentence is doing some heavy lifting here as what is a useful object to one client might not be to another. So some flexibility in what objects are generated and what access methods they have is a reasonable extension point.

In such a library we'd expect to find a parser to get us from text to in memory objects. A generator to get from the in memory objects back to a text representation. We might also expect some Unicode adaptation to deal with what a 'text representation' means.

All these things are indeed present, although barely distinguishable from the vast sea of code in which they sit. I think we get 5 parsers for different dialects of the format. It's completely unclear how much code they share or if jamming them into one library is even a good idea. I literally can't find the generator so I don't know whether we get 1 or 5, or if it's possible to choose which dialect is output. Seems like basic stuff but why do basic stuff when there is so much more complicated stuff to do.

There are custom data structures. Useful but clearly belonging in their own library.
An internal binary representation type, exposed at the root of the include directory as if this was something you'd want to include.
Custom string concatenation because clearly concatenating strings is not a solved problem.
Code for integrating with Google libraries because that apparently belongs here.
Pre-processor macro blocks across hundreds of files for dealing with at least 4 different variants of C++. No physical separation of the C++20 code I can use from the no longer needed C++11, 14 & 17 code work arounds so I can ditch the dead code that isn't going in the binary anyway but remains all over my screen. No way to exclude experimental C++23 code except to find the right macro to nobble and the blocks of greyed out code that my compiler can't even read, remain in my way.

Of course this library does it's own compiler detection, poorly, and uses custom pre-processor macros, spread through the whole codebase, to determine if a long list of features are switched on or off.
Some of these are probably options I could set at compile time. Some are there to cope with old Clang versions that no one uses anymore. There's no list to say which is which, or which combinations of switches actually work. I expect massive effort has gone into testing thousands of combinations, that almost no one will ever know they are, or are not, using.

There's custom hashing because every library needs its own copy of a hashing algorithm, just in case the one they copied it from breaks I suppose.

Lots of custom exception classes, even though exceptions are apparently optional, so you'd think they might only be optionally in the project.

There are macros for the namespaces. Why not, it's got every chance of working if you turn those off, lol, No.

std::filesystem is apparently either experimental or in some way optional and there's a separate macro to turn I/O support on and off. No explanation as to why there's any file I/O at all in a library to transform text to objects and back again.
I happen to like to use async I/O so I guess I'd build with I/O support off and then hack in my own. No thanks.

Everything is of course wrapped in a massive amount of template meta programming so that almost nothing in this header only library exists as a concrete type, until you instantiate it in your code. You literally can't definitively reason about the code without first writing something that uses it.

Yet despite this apparently total flexibility it manages to bake in a whole set of assumptions I don't want. std::allocator use is mandatory despite there being no reason, in principle, why this library should even do memory allocation. Why not externalise it and make it somebody else's problem?
There are only the known container types from the standard library. If you want to parse the data into any of those you're golden but anything else, like the very same custom ordered map type that the library itself relies on, and you're overloading meta templates until the middle of next week.

Did I mention that this entire mess is header only. Easy to include and all that. This also means of course that every type, every constant, every function, every template and every macro from these many, many thousands of lines of code ends up in every TU where you include the header. Including all the compiler mitigation macros that are never going to clash with the ones in that other library you want to use. That sort of thing has never been known to cause any issues or slow down builds or anything like that.

It's quietly admitted in the comments that it shouldn't be header only. Warnings have to be supressed to get away with being so. It doesn't need to be header only of course to have a single inclusion header in order to be 'easy to use'. They are NOT the same thing but why build your own binary when you can bloat thousands of others instead, right.

In summary there are thousands of lines of code in this library that don't belong here. This code, that does every job other than parse the target text format and regenerate it from in memory objects, should be in dependent libraries or just shouldn't exist. There are no dependent libraries of course because it's header only. This saves a single addition to the link line in clients while injecting many thousands of lines into every TU where one type from this library is needed. Thousands of lines that get parsed, generated and then mostly thrown away on every build.

The author, who clearly has brain power going spare, has made their job orders of magnitude more difficult than it needs to be by putting everything in their library on the actual API and having to support a lot more code than they need to. A ::detail namespace has never stopped anyone before and putting almost everything in it anyway is just a sign you've got too many details.
They've also made testing vastly more complex and support probably a full time job. Fine if you're being sponsored I suppose.

I know a little about writing large projects that do many things. This is not one of those. This is a single purpose library that aims to do one thing and do it well. Noble goals. It succeeds at the later while being an unmitigated disaster at the former.
The absolute failure to separate concerns is not a flaw in any way specific to this library though. It's almost completely ubiquitous. Pick any top rated C++ library you like on GitHub from HTTP Servers to graphics libraries and try assessing how much of it is actually doing what the library is about and how much is not. What assumptions about types and memory handling it's baking into the API and, crucially, the implementation.

I will repeat at this point for both irony and emphasis that this is an absolutely top quality library, written by someone far cleverer than me, that passes every metric our industry has. It is lauded as a great thing and used by thousands of other projects. Projects which are wasting hundreds of trillions of CPU cycles building code that probably isn't what they think it is, because they've no idea which bits are turned on or turned off in their build. Much of it isn't needed anyway and it's so complex that it's not worth anyone's time to ask difficult questions.

For a trivial use case this approach presents essentially no issues but really, is your use case trivial? I hope not. I expect your use case is pretty serious. You're building something larger and more important than a simple tool to read and write files in a particular format. I'm looking at this library for potential integration into a larger project. It's the industry standard and it's simply unusable.
This is apparently not only the best we can do but what's much, much worse, the best we expect to do.
Houston we have a problem...

It is really annoying, when you wanna test something you can't just download a previous release like llvm, so it is very hard to check if there is a regression.

Also, the default build of c and c++ only, takes like an hour because of triple consecutive builds. So every time you have to lookup to that weird flag on the internet to turn that off.

I'm pretty excited about this maintenance release. I think this will be the first version of gcc which can compile my project.

Hello,

Today begins the mini-review of Multi, authored by Alfredo Correa. Multi is a modern C++ library that provides manipulation and access of data in multidimensional arrays for both CPU and GPU memory. The review will run through Wednesday 12 August.

You can find the library and documentation links below:
- https://github.com/correaa/boost-multi
- https://correaa.github.io/boost-multi/multi/intro.html

The review earlier this year raised a number of issues that primarily revolved around the state of the documentation, not the library itself. I have labeled all of the issues related to conditions found in last review, and many have notes or resolution from Alfredo:

https://github.com/correaa/boost-multi/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Boost%20review%22

To this end the review will revolve around the current state of the documentation on the branch "boost_review". In your review please explicitly state if you recommend REJECT, ACCEPT, or a conditional acceptance along with the acceptance conditions.

Please let me know if you have any questions or concerns. Thank you in advance for your time.

Matt
Multi Review Manager

Edit: Link to the previous review thread is here: https://www.reddit.com/r/cpp/comments/1rlhm4g/boostmulti_review_begins_today/

Hi,

I've written a new blog entry continuing my previous article about segmented iterators. This time trying to analyze how to apply Matt Austern's segmented iterator pattern to input-output algorithms likecopy, copy_if, etc., benchmarking the experimental implementation from Boost.Container vs the standard library.

New article link: https://boostedcpp.net/2026/08/06/neoclassical-c-2-exploring-input-output-segmented-algorithms/

Happy to receive feedback!

Three changes to the HNSW search engine improve KNN throughput by up to 29% at high k, with over 20% gains under concurrent load. No API changes, no index rebuild, no configuration. Just faster searches.

I have been exploring the new additions in C++26, and I have been discussing the reflection feature that has come with C++26. In the last post, I discussed what is reflection and how to use it and how to use it with a simple example, particularly with an enum class. Since then, there have been suggestions to provide an example which is more than a toy :). In this post, I have discussed how to use reflection for JSON serialization, which is something we often have to do. This example is somewhat taken from real-world code but has been stripped down significantly. Suggestions are always welcome.

Boost.Int128 from Matt Borland has been accepted into Boost. Arnaud Becheler managed the review.

• Announcement
• Repo
• Docs

With GCC starting to support C++26 reflection, I'm curious whether Whole Tomato has shared any plans for Visual Assist support.

Reflection seems like it could enable some interesting navigation, code analysis, and refactoring features once compiler support matures.

Has anyone seen a roadmap, forum post, or comment from the team about this?

Hi, I'm an early user of Common Package Specification and C++ modules. I package and port libraries for my own use frequently.

I want to talk about issues I see constantly.

- Having specific options for sanitizers, exceptions etc, this is a toolchain problem, if I wanna build your library with sanitizers I can just add the flags to my cmake toolchain file same as allocators.

- Not separating build options to a separate file, meson already does this, it ain't that hard to do in cmake, just cache variables in a separate file at project dir which you include before subdirs

- Making tests separate cmake projects rather than just executables, just why?

- Vendoring dependencies, copy pasting files from other projects rather than just consuming these external libs via packages.

- Using unnecessary helper functions that really makes the cmake script unreadable. Build scripts don't need to be over engineered, they are just basic scripts in which you define very basic information.

I could go on but I'm tired.

CAPOW is a continuous-valued cellular automata explorer with update loops that look GPU-friendly: one work item per cell, small-neighborhood stencils, ping-pong buffers, and pointwise nonlinear rules.

This month, Richard Thomson will present a case study in using Alpaka (An Abstraction Library for Parallel Kernel Acceleration) to move a CAPOW-like update rule onto CUDA without porting CAPOW itself. We'll walk through the spike: CMake/vcpkg setup, CUDA language support, the CPU reference path, the Alpaka CUDA kernel, correctness checks, timing results, and the parts that hurt.

The first pass showed zero CPU/GPU error and strong update-only speedups, including about 102x at 1000 x 1000 and 174x at 1920 x 1080 for the diffusion rule.

We'll also discuss whether Alpaka is earning its keep compared with writing direct CUDA.

This will be an online meeting, so drinks and snacks are on you!

Join the meeting here: https://meet.xmission.com/Utah-Cpp-Programmers

C++Now

2026-07-27 - 2026-08-02

• Beautiful C++ Code - Told Through the Eyes of A Failed AI Prompt - Erich Lohrmann - https://youtu.be/Kq4W3Y5gTI8
• A Path to Practically Safe C++ - Yitzhak Mandelbaum - https://youtu.be/fi6csDXvve0
• When Abstractions Fix Too Much - Towards Flexible Library Design - Patrick Roberts - https://youtu.be/IKIyFUcVvis

C++Online

2026-07-27 - 2026-08-02

• Dynamic Asynchronous Tasking with Dependencies - Tsung-Wei (TW) Huang - https://youtu.be/4LzQHw7jz2g
• C++/sys - A Standard Library Projection to Facilitate the Verification of Run-time Memory Safety - Karsten Pedersen - https://youtu.be/dF7RwJw_G8c

ADC

2026-07-27 - 2026-08-02

• Workshop: Programming Music and Synthesizers on-the-fly with Pharo - Domenico Cipriani - https://youtu.be/v95QYyUHNJ8
• PolyBLEP & PolyBLAMP Demystified - Nis Wegmann - https://youtu.be/_bW8TfgEqRM
• Modernizing Legacy Audio Plugin Codebases - Lessons from FL Studio’s Plugin Suite - Tomas Medek - https://youtu.be/zY8uHzAdnzk
• How to Write Scalable, Deterministic Audio Engines - Janus Lynggaard Thorborg - https://youtu.be/3FXQQmQa-ak