std::thread error

Joel Sherrill joel.sherrill at oarcorp.com
Mon Sep 28 20:27:41 UTC 2015



On 9/28/2015 3:20 PM, Jeff Webb wrote:
> 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...

sched.h and it should be in newlib.

I wonder if there is something wrong with microblaze-rtems matching
in libgcc/config.gcc or another configuration file. It is fairly
common to find CPU*-*-* without an rtems specific pattern to match
above it. With this being a new port, that is a likely thing in
the gcc source. It could be in the libstdc++ configuration.

> -Jeff
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


More information about the users mailing list