* libstdc++ for cross compilers
@ 2017-04-10 13:24 Ricardo Wurmus
2017-04-12 9:24 ` Ludovic Courtès
0 siblings, 1 reply; 5+ messages in thread
From: Ricardo Wurmus @ 2017-04-10 13:24 UTC (permalink / raw)
To: help-guix
Hi Guix,
I’m trying to update my custom package for the Axoloti audio board,
which is not yet in Guix because it depends on bundled Java jars. The
package includes a user interface written in Java and a cross-compiled
firmware for the board.
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?
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++ for cross compilers
2017-04-10 13:24 libstdc++ for cross compilers Ricardo Wurmus
@ 2017-04-12 9:24 ` Ludovic Courtès
2017-04-13 8:54 ` Ricardo Wurmus
0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2017-04-12 9:24 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: help-guix
Hello!
Ricardo Wurmus <rekado@elephly.net> 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
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’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?
HTH,
Ludo’.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++ for cross compilers
2017-04-12 9:24 ` Ludovic Courtès
@ 2017-04-13 8:54 ` Ricardo Wurmus
2017-05-20 10:10 ` Ricardo Wurmus
0 siblings, 1 reply; 5+ messages in thread
From: Ricardo Wurmus @ 2017-04-13 8:54 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: help-guix
Hi Ludo,
thanks for the hints.
> Ricardo Wurmus <rekado@elephly.net> 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")
(arguments
(substitute-keyword-arguments (package-arguments libstdc++)
((#:configure-flags flags)
``("--target=arm-none-eabi"
"--disable-libstdcxx-pch"
,(string-append "--with-gxx-include-dir="
(assoc-ref %outputs "out")
"/arm-none-eabi/include"))))))))
--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
newlib-nano.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++ for cross compilers
2017-04-13 8:54 ` Ricardo Wurmus
@ 2017-05-20 10:10 ` Ricardo Wurmus
2017-05-21 13:09 ` Ricardo Wurmus
0 siblings, 1 reply; 5+ messages in thread
From: Ricardo Wurmus @ 2017-05-20 10:10 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: help-guix
Ricardo Wurmus <rekado@elephly.net> writes:
> Hi Ludo,
>
> thanks for the hints.
>
>> Ricardo Wurmus <rekado@elephly.net> 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")
> (arguments
> (substitute-keyword-arguments (package-arguments libstdc++)
> ((#:configure-flags flags)
> ``("--target=arm-none-eabi"
> "--disable-libstdcxx-pch"
> ,(string-append "--with-gxx-include-dir="
> (assoc-ref %outputs "out")
> "/arm-none-eabi/include"))))))))
> --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
> newlib-nano.
It didn’t work. I added a (cross-libc "arm-none-eabi") to the
cross-compiler, but all I got was:
--8<---------------cut here---------------start------------->8---
checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: WARNING: arm/preconfigure: Did not find ARM architecture type; using default
hppa i386 m68k microblaze mips nacl nios2 powerpc s390 sh sparc tile x86_64
configure: running configure fragment for add-on libidn
configure: error:
*** The GNU C library is currently unavailable for this platform.
*** If you are interested in seeing glibc on this platform visit
*** the "How to submit a new port" in the wiki:
*** https://sourceware.org/glibc/wiki/#Development
*** and join the community!
phase `configure' failed after 1.3 seconds
note: keeping build directory `/tmp/guix-build-glibc-cross-arm-none-eabi-2.25.drv-0'
--8<---------------cut here---------------end--------------->8---
It would also have been weird to build with the GNU libc first and then
later drop it and replace it with newlib, which is what’s used to target
the board.
I’ll have to experiment more with this; maybe there’s another way to get
a functioning g++ cross-compiler for this board.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libstdc++ for cross compilers
2017-05-20 10:10 ` Ricardo Wurmus
@ 2017-05-21 13:09 ` Ricardo Wurmus
0 siblings, 0 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2017-05-21 13:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: help-guix
Ricardo Wurmus <rekado@elephly.net> writes:
> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>> 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")
>> (arguments
>> (substitute-keyword-arguments (package-arguments libstdc++)
>> ((#:configure-flags flags)
>> ``("--target=arm-none-eabi"
>> "--disable-libstdcxx-pch"
>> ,(string-append "--with-gxx-include-dir="
>> (assoc-ref %outputs "out")
>> "/arm-none-eabi/include"))))))))
>> --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 turned out to be right there: the configure flags set
“--target” but not “--host”, so libstdc++ wasn’t cross-built.
I have already overcome the problem and will submit a couple of patches
in the coming days.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-05-21 13:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-10 13:24 libstdc++ for cross compilers Ricardo Wurmus
2017-04-12 9:24 ` Ludovic Courtès
2017-04-13 8:54 ` Ricardo Wurmus
2017-05-20 10:10 ` Ricardo Wurmus
2017-05-21 13:09 ` Ricardo Wurmus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).