gcc-5.3.0 libstdc++-v3: configure: error: No support for this host/target combination for arm-none-eabi

[Jonathan Wakely]

On 12 April 2016 at 13:00, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 31 March 2016 at 19:30, onkel.jack@t-online.de
> <onkel.jack@t-online.de> wrote:
>>
>> Thanks Kai.
>>
>> In the meantime I did some more experiments after I figured out I can repro the problem on RHEL6 too which does build much faster ...
>>
>> It turned out, the problem goes away if newlib gets configured with --enable-newlib-multithread, I lost that, for whatever reason.
>> Somehow it seems to have an influence on configure libstdc++. Guess a diff in newlib headers might find it.
>> I think, threading in gcc and newlib needs to be configured consistent despite the "single" default means NO, maybe its different in libstdc++  ...
>
> single means NO, but single is not necessarily the default!
>
> The docs you quoted say:
>
> "Beware that on some systems, GCC has not been taught what threading
> models are generally available for the system. In this case,
> --enable-threads is an alias for --enable-threads=single."
>
> But that's not the case for your target. GCC has been taught what
> threading models are available for arm-geabi using newlib, so when you
> say --enable-threads it assumes you want to enable threads!

Oh sorry, I see it was Kai who quoted those docs.

But anyway, even if you haven't taught libstdc++ about your target it
might be guessing from newlib, and I think this is still relevant:

> If you want to disable threads then use --disable-threads. Using
> --enable-threads to disable threads based on your assumption about a
> default is just silly.