Hi!

As some of you probably know, there are issues using GCC to compile C++ 
code, especially for embedded systems.¹²³⁴⁵

Another problem I encountered is that there is only one libstdc++ 
version, which may not match the GCC version one might wish to use.

I stumbled into these problems while trying to compile some embedded C++ 
stuff for an Arm mirco-controller. So I thought to build GCC from 
scratch including libstdc++ and getting the include paths right, and 
then use that to build the needed cross GCC as well.

Finally I got c-toolchain lists for use with package-with-c-toolchain 
and complete GCC toolchains for installation. Each basically consists 
just of (the union of) GCC and Binutils.

I figured out that for GCC 12 only a single patch seems to be necessary: 
gcc-12-strmov-store-file-names.patch.

In the end it worked nicely for my embedded C++ stuff and I also managed 
to compile a custom keyboard firmware based on ZMK using Zephyr, 
although that is just C code.

The newly build GCC contains these default include paths:

$ /gnu/store/…-gcc12-12.2.0/bin/g++ -v -x c++ -E - < /dev/null
…
#include <...> search starts here:
  /gnu/store/…-gcc12-12.2.0/include-c++
  /gnu/store/…-gcc12-12.2.0/include-c++/x86_64-unknown-linux-gnu
  /gnu/store/…-gcc12-12.2.0/include-c++/backward
 
/gnu/store/…-gcc12-12.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/include
  /gnu/store/…-gcc12-12.2.0-lib/include
 
/gnu/store/…-gcc12-12.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/12.2.0/include-fixed
  /gnu/store/…-glibc-2.33/include
  /gnu/store/…-linux-libre-headers-5.10.35/include
End of search list.
…

This is very similar to the paths found in FHS systems. The path 
/gnu/store/…-gcc12-12.2.0-lib/include is empty and replaces 
/usr/local/include. It is impossible to omit a path at this place.

Similarly the newly build cross GCC with newlib contains these default 
include paths:

$ 
/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-toolchain-12.2.0/bin/arm-none-eabi-g++ 
-v -x c++ -E - < /dev/null
…
#include <...> search starts here:
  /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/include-c++
 
/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/include-c++/arm-none-eabi
  /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/include-c++/backward
 
/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/include
  /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/include
 
/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/include-fixed
  /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/include
End of search list.
…

You may note the missing include path to kernel headers, which do not 
exist for bare-metal builds using newlib. So this is by intention.

None of these paths will show up in C_INCLUDE_PATH or CPLUS_INCLUDE_PATH 
when installing a toolchain, which I think was basically the root of all 
the pain.

Of course this makes use of the already existing gnu-build-system and 
the gcc-toolchain. To get this going gcc-phase-fix-environment is used 
to overcome some troubles with the existing gcc-toolchain.

In the end I think it could make sense to change the way how the tower 
of GCC versions is build. I also think that glibc should reference the 
libgcc_s.so from some gcc-stage1:lib output, which has to be build 
without any libc. Then the modification of the specs to pre-load that 
library via -lgcc_s may become obsolete.

Except for other compilers like clang, this makes a libstdc++ package 
obsolete. I did not care about using clang with lbstdc++ yet, but I 
might do so in the future. I also did not try to use the same functions 
on older GCC versions nor GCC 13, which was not existing in Guix when I 
started this endeavor.

I hope this message triggers some interest and helps solving some 
existing troubles.


Bye

Stefan


P.S. If someone likes to play with the attached files, please note the 
needed file structure:
…/embedded.scm
…/zephyr.scm
…/zephyr/modules.scm
…/zephyr/apps.scm
…/zephyr/zmk.scm


¹ https://lists.gnu.org/archive/html/help-guix/2023-09/msg00025.html
² https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00096.html
³ https://issues.guix.gnu.org/37801
⁴ https://issues.guix.gnu.org/43579
⁵ https://issues.guix.gnu.org/49935