std::thread error

[Jeff Webb]

On 09/28/2015 03:27 PM, Joel Sherrill wrote:
>
>
> 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.

To me, it looks like this:

libgcov-interface.c includes gthr.h
gthr.h includes gthr-default.h.
gthr-default.h includes pthread.h
newlib/libc/include/pthread.h is found first, which does not include sched.h
after including pthread.h, gthr-default.h tries to reference sched_yield
   i.e.: "__gthrw(sched_yield)"
gthr-default.h then includes sched.h later in the file.
sched.h defines sched_yield, but it is too late.

Of course, I could easily be confused.

-Jeff