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@xxxxxxxxx> An: "Kai Ruottu" <kai.ruottu@xxxxxxxxxxx> On 12 April 2016 at 14:42, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 12 April 2016 at 14:28, Kai Ruottu <kai.ruottu@xxxxxxxxxxx> 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 :-)
