[Top][All Lists]

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

Re: libstdc++ for cross compilers

From: Ricardo Wurmus
Subject: Re: libstdc++ for cross compilers
Date: Thu, 13 Apr 2017 10:54:28 +0200
User-agent: mu4e 0.9.18; emacs 25.1.1

Hi Ludo,

thanks for the hints.

> Ricardo Wurmus <address@hidden> skribis:
>> The latest version includes C++ sources for the firmware.
>> Unfortunately, our “arm-none-eabi” cross-compiler package does not
>> build libstdc++, nor does it come with any of the required C++ headers
>> like “cmath”.
>> So I tried to change our “arm-none-eabi” cross-compiler packages to also
>> build and install libstdc++ but failed in a multitude of ways.  The end
>> result is always that either the compiler fails to build (e.g. when
>> enabling libstdc++ via configure flags) or that the compiler fails to
>> find the header files that are included via “#include_next” directives
>> (e.g. when building libstdc++ as a separate package).
>> Could someone with GCC experience give me a hint despite my vague
>> problem description?
> libstdc++ itself can probably be cross-built with:
>   guix build libstdc++ --target=arm-none-eabi

I created a package variant like this:

--8<---------------cut here---------------start------------->8---
(define-public libstdc++-arm-none-eabi
  (let* ((xgcc gcc-arm-none-eabi-6)
         (libstdc++ (make-libstdc++ xgcc)))
    (package (inherit libstdc++)
      (name "libstdc++-arm-none-eabi")
       (substitute-keyword-arguments (package-arguments libstdc++)
         ((#:configure-flags flags)
             ,(string-append "--with-gxx-include-dir="
                             (assoc-ref %outputs "out")
--8<---------------cut here---------------end--------------->8---

And adding it to the inputs for the Axoloti firmware seems to be fine
for a while until it fails to find headers with “#include_next”.  I’ll
try to gather some better error messages.

> The problem is getting a cross-g++.  I suspect libstdc++ sorta relies on
> having a “real” libc, which is why we normally do things like:
>    (let ((triplet "arm-linux-gnueabihf"))
>      (cross-gcc triplet
>                 (cross-binutils triplet)
>                 (cross-libc triplet))))
> where the final ‘cross-gcc’ has C++ support.

I find this confusing because the binary release of the arm-none-eabi
cross-compiler includes the libstdc++ headers — and it doesn’t appear to
use the GNU libc at all.  It includes two libc variants which were both
derived from newlib (regular and “nano” configurations).

> I’m not sure if it makes sense for the board you’re targeting, but maybe
> you could try building with a full-blown cross-gcc like this?

I can give it a try but I don’t think it makes sense for the board.
It’s not supposed to use anything but the special implementations of


GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC

reply via email to

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