Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Jean-Pierre De Jesus Diaz writes: > I haven't contributed it yet because it has been a bit hard adapting axoloti-* > packages to use a modern toolchain because I'm also intending to remove > the old toolchains in `gnu/packages/embedded.scm' eventually and > instead use the ones in `cross-gcc-toolchain'. Could you explain why it is difficult to adjust the axoloti/ksoloti packages? They only need an arm-none-eabi cross-compiler with newlib. Since I have axoloti boards here, I could test your changes. -- Ricardo
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hello, Adding to this conversation I have been making a arm-none-eabi toolchain with Newlib included as the default C standard library like in the official Arm toolchain but I'm not quite happy with the patches yet.[1] I haven't contributed it yet because it has been a bit hard adapting axoloti-* packages to use a modern toolchain because I'm also intending to remove the old toolchains in `gnu/packages/embedded.scm' eventually and instead use the ones in `cross-gcc-toolchain'. [1]: https://github.com/Foundation-Devices/guix-mirror/compare/master...wip/arm-none-eabi On Fri, May 24, 2024 at 3:53 PM Sergio Pastor Pérez wrote: > > Hi both of you. > > I want to echo Attila's sentiments. This is a valuable contribution, and > creating a channel would serve as a central hub for other contributors. > > Thanks for sharing, Stefan. > > Have nice day. > Sergio. >
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi both of you. I want to echo Attila's sentiments. This is a valuable contribution, and creating a channel would serve as a central hub for other contributors. Thanks for sharing, Stefan. Have nice day. Sergio.
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
hi Stefan, > > Does anyone know if this is available in a public repository? Or if it has > > been moved forward? > > > There is no public repository for it. this is a much more valuable piece of contribution than to allow it to hang in the void indefinitely! if the only reason that you have not made a channel for this yet is that you've never done it before, then i'd be happy to walk you through it off list. or i can help you setting up a guix fork where you can push your own signed commits, and guix pull from. or if you don't mind that the initial commit will be signed by me, then i can even set up a guix channel on codeberg, give you commit access, and then you can push any further changes there. just let me know. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Fear is not in the habit of speaking truth; when perfect sincerity is expected, perfect freedom must be allowed; nor has anyone, who is apt to be angry when he hears the truth, any cause to wonder that he does not hear it.” — Cornelius Tacitus (ca. 56–117)
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi Sergio! I'm very interested in the code for ZMK provided in this thread[1]. I've tried it locally and it compiles successfully. That's nice to hear! Does anyone know if this is available in a public repository? Or if it has been moved forward? There is no public repository for it. I moved it a bit further. There is now a GCC with picolibc. GCC in general is more self-contained and is completely usable by itself (including paths to specs; Attila, this may solve the issue you were facing). There is no real need for GCC-toolchain packages anymore. However, as some projects invoke programs of Binutils directly and because of locales, there are still GCC-toolchain packages. The Binutils for arm-none-eabi get build separately as well now, as the one from Guix has failing tests (if activated) due to the selected configure flags. GCC is bumped to 13.2.0. Zephyr is updated to 3.5 and ZMK to end of April. There is also more ZMK support for combos, conditional-layers and a bit more. A problem I figured for arm-none-eabi-g++ is that it always links the generic libstdc++.a, instead of the existing CPU and FPU specific multilib variant from a sub-directory. I'd appreciate any GCC configuration hint to solve this. Anyone here have tried to do something with ZMK? I'm interested in what would be the Guix approach for ZMK development. The blog post of Zephyr[2] was a very interesting read, does anyone know of other resources regarding this topic? I'm not aware of anything else regarding ZMK or Zephyr in Guix. Bye Stefan embedded.tar.gz Description: application/gzip
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hello. I'm very interested in the code for ZMK provided in this thread[1]. I've tried it locally and it compiles successfully. Does anyone know if this is available in a public repository? Or if it has been moved forward? Anyone here have tried to do something with ZMK? I'm interested in what would be the Guix approach for ZMK development. The blog post of Zephyr[2] was a very interesting read, does anyone know of other resources regarding this topic? Have a great day! Sergio. [1]: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00014.html [2]: https://guix.gnu.org/en/blog/2023/building-toolchains-with-guix
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
TL;DR it's probably due to some cmake mess. and i gave up on compiling this; if i really want to, i'll do it in a debian chroot. > > i tried with your gcc … but it errors out with: > > > > $ make > > [ 1%] Linking ASM executable bs2_default.elf > > arm-none-eabi-gcc: error: nosys.specs: No such file or directory > > > That file is located here: > /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib/nosys.specs that didn't help: ~/workspace/guix/guix/pre-inst-env guix shell gcc-toolchain cmake make pkg-config -e '(@ (gnu packages embedded2) gcc12-cross-newlib-arm-none-eabi-toolchain)' cd ~/workspace/bios/pico-serprog cmake . COMPILER_PATH=/gnu/store/i9kpjzbagdlpm8bs10gxmm21b271s056-newlib-3.0.0-0.3ccfb40/arm-none-eabi/lib/ LDFLAGS=-B/gnu/store/i9kpjzbagdlpm8bs10gxmm21b271s056-newlib-3.0.0-0.3ccfb40/arm-none-eabi/lib/ make it leads to the same problem. but then i tried to compile the pico-sdk subproject as a standalone project, and then it succeeds (but fails with a different error later). therefore i think it's due to some cmake mess that i don't want to get deeper into. so, the rest is just FYI: git clone https://github.com/raspberrypi/pico-sdk ~/workspace/guix/guix/pre-inst-env guix shell gcc-toolchain cmake make pkg-config -e '(@ (gnu packages embedded2) gcc12-cross-newlib-arm-none-eabi-toolchain)' cmake . make $ make [ 0%] Building ASM object src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/compile_time_choice.S.obj [ 0%] Linking ASM executable bs2_default.elf [ 0%] Built target bs2_default [ 0%] Creating directories for 'ELF2UF2Build' [ 0%] No download step for 'ELF2UF2Build' [ 0%] No update step for 'ELF2UF2Build' [ 0%] No patch step for 'ELF2UF2Build' [ 0%] Performing configure step for 'ELF2UF2Build' -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed -- Check for working C compiler: /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc -- Check for working C compiler: /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc - broken CMake Error at /gnu/store/4bn07jsqk6lxp0qdxv7kkc3krz3afnna-cmake-3.25.1/share/cmake-3.25/Modules/CMakeTestCCompiler.cmake:70 (message): The C compiler "/gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY Run Build Command(s):/gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/make -f Makefile cmTC_12bac/fast && make[3]: Entering directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/make -f CMakeFiles/cmTC_12bac.dir/build.make CMakeFiles/cmTC_12bac.dir/build make[4]: Entering directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' Building C object CMakeFiles/cmTC_12bac.dir/testCCompiler.c.o /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc-o CMakeFiles/cmTC_12bac.dir/testCCompiler.c.o -c /home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY/testCCompiler.c as: unrecognized option '--64' make[4]: *** [CMakeFiles/cmTC_12bac.dir/build.make:78: CMakeFiles/cmTC_12bac.dir/testCCompiler.c.o] Error 1 make[4]: Leaving directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' make[3]: *** [Makefile:127: cmTC_12bac/fast] Error 2 make[3]: Leaving directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' the root cause of the messy error message above is the following: as: unrecognized option '--64' this happens with the host gcc (or due to some misconfiguration the host gcc is used wrongly). $ file src/rp2_common/boot_stage2/bs2_default.elf src/rp2_common/boot_stage2/bs2_default.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery (1900–1944)
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi Jean-Pierre! The arm-none-eabi target is not finished yet since I'm running into some issues when building Axoloti which depends on the (gnu packages embedded) toolchains and I'm trying to migrate it to use `cross-gcc-toolchain` but it is proving a bit difficult due to search paths but I'm trying to solve it anyway. These include path problems where exactly the problems which I solved with that gcc12 and gcc12-cross packages. Let's say that they are a proof-of-concept for a better way to build GCC, not relying on environment variables for standard include paths. My gut feeling is that the whole GCC version chain starting in (gnu packages commencement) should be build this way, and in the end also the cross-gcc-toolchain would not have these issues. However, I think that would be an enormous effort – a bit like rewriting the bootstrapping of Guix – and I have no clue how to start myself with it. Bye Stefan
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi Attila! i tried with your gcc … but it errors out with: $ make [ 1%] Linking ASM executable bs2_default.elf arm-none-eabi-gcc: error: nosys.specs: No such file or directory That file is located here: /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib/nosys.specs Hm, it might be necessary to add that path per default to COMPILER_PATH as well with a -B option. This path currently only appears under LIBRARY_PATH, which seems to not be searched for spec files. $ arm-none-eabi-g++ -v -E -xc++ - < /dev/null Using built-in specs. COLLECT_GCC=/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-toolchain-12.2.0/bin/arm-none-eabi-g++ Target: arm-none-eabi Configured with: Thread model: single Supported LTO compression algorithms: zlib gcc version 12.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-mcpu=arm7tdmi' '-mfloat-abi=soft' '-marm' '-mlibarch=armv4t' '-march=armv4t' /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/12.2.0/cc1plus -E -quiet -v -D__USES_INITFINI__ - -mcpu=arm7tdmi -mfloat-abi=soft -marm -mlibarch=armv4t -march=armv4t -dumpbase - ignoring nonexistent directory "/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/../../../../../../../arm-none-eabi/include" #include "..." search starts here: #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. # 0 "" # 0 "" # 0 "" # 1 "" COMPILER_PATH=/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/ LIBRARY_PATH=/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-v' '-E' '-mcpu=arm7tdmi' '-mfloat-abi=soft' '-marm' '-mlibarch=armv4t' '-march=armv4t' You may want to try to add -B /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib to the linker options or to add COMPILER_PATH=/gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib in front of your command. Tell me about your results. I'm about to update to GCC 13. There is some issue to work around (which smells like a similar one in Gentoo¹), I’ll see if I can add the newlib path to the COMPILER_PATH as well. Bye Stefan ¹ https://bugs.gentoo.org/905118
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hello everyone, I was working before on embedded toolchains with Guix and added AVR platform as a result. [1] Just FYI, I have a WIP patch series to add support for arm-none-eabi using the Guix cross compilation methods, e.g.: using #:target and so on and also to add an user installable toolchain as done with AVR on [1]. The arm-none-eabi target is not finished yet since I'm running into some issues when building Axoloti which depends on the (gnu packages embedded) toolchains and I'm trying to migrate it to use `cross-gcc-toolchain` but it is proving a bit difficult due to search paths but I'm trying to solve it anyway. >$ make >[ 1%] Linking ASM executable bs2_default.elf >arm-none-eabi-gcc: error: nosys.specs: No such file or directory > >IIRC, this happens with the vanilla guix packages when i try to use a gcc >package instead of a gcc-toolchain package. This happens when the toolchain doesn't have the Newlib C library which includes the nosys.specs file so probably if Newlib is present it's then that GCC can't find the specs file. [1]: https://issues.guix.gnu.org/66263 -- Jean-Pierre De Jesus DIAZ Foundation Devices, Inc.
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
hi Stefan, > 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. i've also encountered a problem with the guix cross compiling tools as i have described here: https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00179.html i tried with your gcc (copied into guix as (gnu packages embedded2)): ~/workspace/guix/guix/pre-inst-env guix shell gcc-toolchain cmake make pkg-config -e '(@ (gnu packages embedded2) gcc12-cross-newlib-arm-none-eabi-toolchain)' cd ~/workspace/bios/pico-serprog cmake . make but it errors out with: $ make [ 1%] Linking ASM executable bs2_default.elf arm-none-eabi-gcc: error: nosys.specs: No such file or directory IIRC, this happens with the vanilla guix packages when i try to use a gcc package instead of a gcc-toolchain package. any thoughts on this? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “There can be no causeless love or any sort of causeless emotion. An emotion is a response to a fact of reality, an estimate dictated by your standards.” — Ayn Rand (1905–1982)
A different way to build GCC to overcome issues, especially with C++ for embedded systems
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 ;;; GNU Guix --- Functional package management for GNU ;;; ;;; Copyright © 2023 Stefan ;;; ;;; This file is not part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; GNU Guix is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General
