std::thread error
Jeff Webb
jeff.webb at nta-inc.net
Mon Sep 28 20:20:13 UTC 2015
On 09/28/2015 12:32 PM, Jeff Webb wrote:
> On 09/28/2015 12:01 PM, Jeff Webb wrote:
>> I have now compiled and run my own POSIX C test application that uses pthreads and message queues. Now, I am trying to get a similar C++ test application to work, but I can't get code that references std::thread to compile. I seem to have the same problem that is mentioned here:
>>
>> https://lists.rtems.org/pipermail/users/2015-July/029304.html
>>
>> I wasn't sure of the proper way to pass in the --enable-threads=posix configure option into the source builder tool, so I changed --enable-threads to --enable-threads=posix in:
>>
>> rtems-source-builder/source-builder/config/gcc-common-1.cfg
>>
>> but I now get the following errors when building gcc (parallel build):
>>
>> /home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/gcc-4.9.3/newlib/libc/include/sys/types.h:318:26: fatal error: sys/cpuset.h: No such file or directory
>> #include <sys/cpuset.h>
>> /home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/gcc-4.9.3/newlib/libc/include/sys/
>> types.h:183:9: error: unknown type name '_mode_t'
>> typedef _mode_t mode_t;
>>
>> It looks like the enable-threads=posix option was passed in properly according to the build log:
>>
>> ../gcc-4.9.3/configure --prefix=/opt/rtems/compiler/4.11 --bindir=/opt/rtems/compiler/4.11/bin --exec_prefix=/opt/rtems/compiler/4.11 --includedir=/opt/rtems/compiler/4.11/include --libdir=/opt/rtems/compiler/4.11/lib --libexecdir=/opt/rtems/compiler/4.11/libexec --mandir=/opt/rtems/compiler/4.11/share/man --infodir=/opt/rtems/compiler/4.11/share/info --datadir=/opt/rtems/compiler/4.11/share --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv
>> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r
>> ,
>> koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads=posix --disable-plugin --enable-obsolete --enable-libgomp --enable-languages=c,c++
>>
>> One of the compile commands that generated an error was this:
>>
>> /home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/./gcc/xgcc -B/home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/arm-rtems4.11/newlib/ -isystem /home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/build/arm-rtems4.11/newlib/targ-include -isystem /home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/gcc-4.9.3/newlib/libc/include -B/opt/rtems/compiler/4.11/arm-rtems4.11/bin/ -B/opt/rtems/compiler/4.11/arm-rtems4.11/lib/ -isystem /opt/rtems/compiler/4.11/arm-rtems4.11/include -isystem /opt/rtems/compiler/4.11/arm-rtems4.11/sys-include -g -O2 -mthumb -O2
>> -I../../../../gcc-4.9.3/libgcc/../newlib/li
>> b
>> c/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I../../../../gcc-4.9.3/libgcc -I../../../../gcc-4.9.3/libgcc/. -I../../../../gcc-4.9.3/libgcc/../gcc -I../../../../gcc-4.9.3/libgcc/../include -DHAVE_CC_TLS -o _gcov_execv.o -MT _gcov_execv.o -MD -MP -MF _gcov_execv.dep -DL_gcov_execv -c ../../../../gcc-4.9.3/libgcc/libgcov-interface.c
>>
>>
>> It looks like cpuset.h is found here:
>>
>> /opt/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-linux-gnu-1/newlib-2.2.0.20150423/newlib/libc/sys/rtems/sys/cpuset.h
>>
>> but "newlib-2.2.0.20150423/newlib/libc/sys/rtems" is not in the include path, as far as I can tell, only the include subdirectory is.
>>
>> Even though I knew it was a bad idea, I forced the creation of some symlinks, which causes cpuset.h to be found, but the rabbit hole just gets deeper after that with a host of other errors.
>>
>> Does anyone have an idea of what is going wrong?
>
> Sorry, I guess I need a newer snapshot of newlib.
>
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a
>
> I will to modify the config to use a newer snapshot. Can I checkout directly from git? I can't use the ftp protocol from my office.
After updating the source builder to use a git checkout of newlib, I get a new series of errors starting with:
/home/sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150924-x86_64-linux-gnu-1/build/./gcc/xgcc -B/home/sw/rtems/
rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150924-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/sw/rtems/rtems-sou
rce-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150924-x86_64-linux-gnu-1/build/arm-rtems4.11/newlib/ -isystem /home/sw/rtems/rtems-
source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150924-x86_64-linux-gnu-1/build/arm-rtems4.11/newlib/targ-include -isystem /home/
sw/rtems/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150924-x86_64-linux-gnu-1/gcc-4.9.3/newlib/libc/include -B/opt/rte
ms/compiler/4.11/arm-rtems4.11/bin/ -B/opt/rtems/compiler/4.11/arm-rtems4.11/lib/ -isystem /opt/rtems/compiler/4.11/arm-rtems4.11/include -isystem
/opt/rtems/compiler/4.11/arm-rtems4.11/sys-include -g -O2 -mthumb -O2 -I../../../../gcc-4.9.3/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DI
N_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-defini
tion -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc
-I../../../../gcc-4.9.3/libgcc -I../../../../gcc-4.9.3/libgcc/. -I../../../../gcc-4.9.3/libgcc/../gcc -I../../../../gcc-4.9.3/libgcc/../include -D
HAVE_CC_TLS -o _satfractUTQDQ.o -MT _satfractUTQDQ.o -MD -MP -MF _satfractUTQDQ.dep -DL_satfract -DFROM_UTQ -DTO_DQ -c ../../../../gcc-4.9.3/libgc
c/fixed-bit.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../gcc-4.9.3/libgcc/gthr.h:148:0,
from ../../../gcc-4.9.3/libgcc/libgcov-interface.c:27:
./gthr-default.h:113:9: error: 'sched_yield' undeclared here (not in a function)
__gthrw(sched_yield)
^
./gthr-default.h:90:19: note: in definition of macro '__gthrw2'
static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
^
./gthr-default.h:113:1: note: in expansion of macro '__gthrw'
__gthrw(sched_yield)
^
In file included from ../../../gcc-4.9.3/libgcc/gthr.h:148:0,
from ../../../gcc-4.9.3/libgcc/libgcov-interface.c:27:
./gthr-default.h:113:9: error: 'sched_yield' undeclared here (not in a function)
__gthrw(sched_yield)
^
./gthr-default.h:90:19: note: in definition of macro '__gthrw2'
static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
^
./gthr-default.h:113:1: note: in expansion of macro '__gthrw'
__gthrw(sched_yield)
^
./gthr-default.h: In function '__gthread_yield':
./gthr-default.h: In function '__gthread_yield':
./gthr-default.h:92:25: error: called object '__gthrw_sched_yield' is not a function or function pointer
# define __gthrw_(name) __gthrw_ ## name
I can't seem to track down where sched_yield is defined...
-Jeff
More information about the users
mailing list