12.4.2016, 16:53, Jonathan Wakely kirjoitti:
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 :-)
I had already tried the '--enable-threads' and it didn't make any
difference to the
earlier '--disable-threads'. But using '--enable-threads=posix' caused
errors during
the libgcc build :
/home/src/gcc-5.3.0/build/./gcc/xgcc -B/home/src/gcc-5.3.0/build/./gcc/
-nostdinc -B/home/src/gcc-5.3.0/build/arm-eabi/newlib/ -isystem
/home/src/gcc-5.3.0/build/arm-eabi/newlib/targ-include -isystem
/home/src/gcc-5.3.0/newlib/libc/include
-B/home/src/gcc-5.3.0/build/arm-eabi/libgloss/arm
-L/home/src/gcc-5.3.0/build/arm-eabi/libgloss/libnosys
-L/home/src/gcc-5.3.0/libgloss/arm -B/opt/cross/arm-eabi/bin/
-B/opt/cross/arm-eabi/lib/ -isystem /opt/cross/arm-eabi/include -isystem
/opt/cross/arm-eabi/sys-include -g -O2 -mthumb -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -fno-inline -I. -I. -I../../.././gcc
-I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc
-I../../../../libgcc/../include -DHAVE_CC_TLS -o emutls.o -MT emutls.o
-MD -MP -MF emutls.dep -fexceptions -c ../../../../libgcc/emutls.c
-fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../../libgcc/gthr.h:148:0,
from ../../../../libgcc/emutls.c:31:
./gthr-default.h:47:9: error: unknown type name 'pthread_t'
typedef pthread_t __gthread_t;
^
./gthr-default.h:48:9: error: unknown type name 'pthread_key_t'
Although those :
-isystem /home/src/gcc-5.3.0/build/arm-eabi/newlib/targ-include -isystem
/home/src/gcc-5.3.0/newlib/libc/include
-B/home/src/gcc-5.3.0/build/arm-eabi/libgloss/arm
-L/home/src/gcc-5.3.0/build/arm-eabi/libgloss/libnosys
-L/home/src/gcc-5.3.0/libgloss/arm
were there, all the required directories to have the newlib headers
weren't! The 'build/arm-eabi' had none of those
'newlib' and 'libgloss' subdirs yet. But the newlib source directories
'/home/src/gcc-5.3.0/newlib/libc/include' and
'/home/src/gcc-5.3.0/libgloss/arm' of course were available. But this
probably wasn't the reason, these data types
were defined in 'newlib/libc/include/sys/types.h' but that required
defining '_POSIX_THREADS' first somewhere...
The newlib 'include/sys/features.h' defines it only for 'rtems', 'XMK'
and 'CYGWIN'...
The symlinked 'newlib' and 'libgloss' subdirs were from the
'newlib-2.4.0' sources.
The never-heard-before 'XMK' seems to be a new RTOS :
https://en.wikipedia.org/wiki/XMK_%28operating_system%29
When I didn't know what the heck I was doing, I decided to leave my
experiments here :)
