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

["onkel dot jack at t-online dot de" <onkel dot jack at t-online dot de>]

Jonathan, Kai,

for the question about threads:
I currently writing a tiny "operating system kernel" named "NANIX" (nano posix) which does provide threads. The thread API will become a posix subset later on.

So my naive idea was to try to configure in a way some things might become reenrant/thread safe to some extend initially so I can develop and test the stuff.
Indeed, I can run a couple of threads (as much as will fit in 32Kb ram ;-) ).

I build with newlib wich also is thread-enabled and take the os provided locks (sys/lock.h) 

For the build problem, I was wrong, the --enable-threads option did not cause any problem as long as I no say =posix, then I miss pthread.h -- a task for later.
The problem seems caused by   --with-gnu-as --with-gnu-ld or maybe from --with-newlib=../$(NEWLIB).
As I said, I took them from some old build script I found on the web, a mistake that might happen to "newbies" ;-)

OJ


-----Original-Nachricht-----
Betreff: Re: gcc-5.3.0 libstdc++-v3: configure: error: No support for this host/target combination for arm-none-eabi
Datum: 2016-04-12T15:54:08+0200
Von: "Jonathan Wakely" <jwakely.gcc@gmail.com>
An: "Kai Ruottu" <kai.ruottu@wippies.com>

On 12 April 2016 at 14:42, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 12 April 2016 at 14:28, Kai Ruottu <kai.ruottu@wippies.com> wrote:
>> 12.4.2016, 16:14, Kai Ruottu kirjoitti:
>>>
>>> But I cannot "grok" how the bare "arm-eabi" object
>>> format or the generic newlib C library could provide that required
>>> "operating system"
>>> for threads.
>>>
>>
>> What newlib can do is to provide code which works when used in threads :
>>
>> https://en.wikipedia.org/wiki/Thread_safety
>>
>> From my own "low-level" programming time, terms like "re-entrant" came quite
>> familiar :)
>
>
> Libstdc++ doesn't care about OS support for threads, it cares about an
> available API for threads, such as Pthreads.
>
> newlib includes a <pthread.h> file that implements the Pthreads API,
> and so you can configure libstdc++ with --enable-threads=posix when
> using newlib (although I assume this requires that newlib itself has
> been configured with Pthreads support enabled).
>
> So I stand by my assertion that using newlib does not necessarily
> imply that the default thread model is "single".


Looking through the libstdc++ I don't see why this error happened. It
looks like the error might have come from the --enable-tls checks, but
I don't see why --enable-threads should affect that, and I agree that
--enable-threads=single *should* be the default for bare metal. But I
still think saying --enable-threads if you don't want threads is
strange, and if removing it solves the problem then that seems like
the best solution :-)
ï