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