aarch64-none-elf build broken

aarch64-none-elf build broken

[Christophe Lyon]

Hi,

As I reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
GCC for aarch64*-none-elf fails when configuring libstdc++ since
r261034 (a week ago).

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.

Maybe I missed a change about this in newlib, and I should upgrade the
version I use for GCC automatic validations?

If not, and if there is not much interest in these configurations,
maybe I should just drop them from my list? Alternatively, I could try
to use LDFLAGS_FOR_TARGET=--specs=rdimon.specs in my validation
scripts.

Or, better, are there plans to fix this?

I ask, because I have no immediate plans to look at this.

Thanks,

Christophe

Re: aarch64-none-elf build broken

[Jonathan Wakely]

On 8 June 2018 at 14:22, Christophe Lyon wrote:
> Hi,
>
> As I reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
> GCC for aarch64*-none-elf fails when configuring libstdc++ since
> r261034 (a week ago).

Sorry for not trying to fix it, I'm travelling and not been able to
look into it (which is why I've only been doing trivial refactoring
patches all week).


> 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.

Re: aarch64-none-elf build broken

[Christophe Lyon]

On 8 June 2018 at 16:41, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 8 June 2018 at 14:22, Christophe Lyon wrote:
>> Hi,
>>
>> As I reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
>> GCC for aarch64*-none-elf fails when configuring libstdc++ since
>> r261034 (a week ago).
>
> Sorry for not trying to fix it, I'm travelling and not been able to
> look into it (which is why I've only been doing trivial refactoring
> patches all week).
>
I'm not blaming you in any way :)


>
>> 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.

That's because aarch64-elf-gcc conftest.c -o conftest fails to link if
one does not provide --specs=rdimon.specs.

So, every configure test that involves a link phase fails.

Re: aarch64-none-elf build broken

[Joseph Myers]

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.  (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++.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: aarch64-none-elf build broken

[Jonathan Wakely]

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 ...)