This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: aarch64-none-elf build broken
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Christophe Lyon <christophe dot lyon at linaro dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 8 Jun 2018 16:40:13 +0100
- Subject: Re: aarch64-none-elf build broken
- References: <CAKdteObzFC88ixvV2_=b4aHPAwBA3f49FOQevqWfE3XdxA44Rw@mail.gmail.com> <CAH6eHdRiOVG=HZf0wtPhE-NFsozcaYFFUW1q_-UmhY1U0j46Mw@mail.gmail.com> <alpine.DEB.2.20.1806081508340.25592@digraph.polyomino.org.uk>
On 8 June 2018 at 16:11, Joseph Myers wrote:
> On Fri, 8 Jun 2018, Jonathan Wakely wrote:
>
>> > The root cause is PR66203 which I reported quite some time ago, which
>> > points to a newlib problem: on aarch64 there is no default rom
>> > monitor, one has to explicitly use a --specs flag for the link to
>> > succeed.
>>
>> I have no idea why this causes the libstdc++ configuration problem
>> though, I don't understand the issue.
>
> Generically libstdc++ should not be doing link tests for bare-metal
> targets; rather, there is a hardcoded set of defines in configure.ac for
> functions present on such targets.
Thanks, I thought that might be how we need to fix this.
> (For most other targets, link tests
> *should* be run even when cross-compiling, there have been plenty of bugs
> in the past where something tested in the $GLIBCXX_IS_NATIVE case wasn't
> also tested in crossconfig.m4 for targets such as GNU/Linux where a target
> libc is guaranteed to be linkable against for building libstdc++.)
Yes, this requirement is very fragile and introduces differences
(sometimes serious ones) between native and cross builds (e.g.
r260678, r258468, r244169 ...)