guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A different way to build GCC to overcome issues, especially with C++ for


From: Stefan
Subject: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Date: Mon, 2 Oct 2023 20:55:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0

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/37801https://issues.guix.gnu.org/43579https://issues.guix.gnu.org/49935

Attachment: embedded.scm
Description: Text Data

Attachment: zephyr.scm
Description: Text Data

Attachment: modules.scm
Description: Text Data

Attachment: apps.scm
Description: Text Data

Attachment: zmk.scm
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]