Re: sys/types.h is broken for _POSIX_THREADS

[Renato Caldas <seventhguardian at gmail dot com>]

On Wed, Feb 24, 2010 at 1:49 AM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
> On 02/23/2010 06:19 PM, Renato Caldas wrote:
>>
>> On Tue, Feb 23, 2010 at 11:35 PM, Jeff Johnston<jjohnstn@redhat.com>
>> ?wrote:
>>
>>>
>>> On 23/02/10 05:41 PM, Renato Caldas wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> I've been trying to compile rtems for a few days, it always failed
>>>> with a strange error message. Now I belive I found out why: I had
>>>> compiled gcc with --enable-threads.
>>>>
>>>> I managed to find one problem. In sys/types.h there is:
>>>>
>>>> #if defined(_POSIX_THREADS)&& ? ?!defined(__CYGWIN__)
>>>> (...)
>>>>
>>>> #if defined(__XMK__)
>>>> typedef struct pthread_attr_s {
>>>> (...)
>>>> } pthread_attr_t;
>>>>
>>>> (...)
>>>>
>>>> #else /* !defined(__XMK__) */
>>>> typedef struct {
>>>> (...)
>>>> #endif /* !defined(__XMK__) */
>>>>
>>>> (...)
>>>> } pthread_attr_t;
>>>>
>>>> (...)
>>>>
>>>> #endif /* defined(_POSIX_THREADS) */
>>>>
>>>> This is clearly broken, because a spurious "} pthread_attr_t" is
>>>> placed in the code #if defined(__XMK__). The fix seems to be easy.
>>>>
>>>>
>>>
>>> Thanks for catching this.
>>>
>>> It appears some __XMK__ patches weren't applied right as there was also
>>> some
>>> redundant checking for __XMK__ being performed. ?I have posted a patch.
>>>
>>
>> Thanks! Disabling thread support in gcc doesn't fix it though, so it
>> must be something else...
>>
>>
>>>>
>>>> I assume thread support is severely broken, or at least severely
>>>> untested, right? If so, wouldn't it be wiser to just make sure it is
>>>> disabled?
>>>>
>>>>
>>>
>>> You'll have to take that up on the RTEMS lists as the thread support code
>>> isn't actually in newlib and RTEMS is tested by the RTEMS folks. Cygwin
>>> also
>>> uses thread support and I would assume it is working fine as they are
>>> pretty
>>> quick to report issues.
>>>
>>
>> It seems the cygwin code takes a different route:
>> #if defined(_POSIX_THREADS)&& ? !defined(__CYGWIN__)
>>
>> My feeling is that few people actually build RTEMS in non-windows
>> hosts :) I'll bug the RTEMS folks tomorrow, thanks.
>>
>>
>
> You would be wrong. ?Most people build RTEMS on
> non-Windows hosts. :) ?I would say now we are evenly
> split between Fedora, Centos, and Ubuntu with a
> fair number of MacOS users. :)

I'm glad I'm using Fedora then :)

> Are you using our prebuilt RPMs? ?How are you building
> the tools.

No, I'm building them myself. The basic idea is:

export gcc_version=4.4.3
export binutils_version=2.20
export newlib_version=1.18.0
export gdb_version=7.0
export TARGET=arm-rtems4.10-eabi

binutils/configure \
    --target=$TARGET \
    --prefix=$PREFIX \
    --enable-interwork \
    --enable-multilib \
    --with-gnu-as \
    --with-gnu-ld \
    --disable-nls

(...)
gcc/configure \
    --target=$TARGET \
    --prefix=$PREFIX \
    --enable-interwork \
    --enable-multilib \
    --enable-languages="c,c++" \
    --with-newlib \
    --with-gnu-as \
    --with-gnu-ld \
    --disable-shared \
    --without-headers
make all-gcc install-gcc

(...)
newlib/configure \
    --target=$TARGET \
    --prefix=$PREFIX \
    --enable-interwork \
    --enable-multilib \
    --with-gnu-as \
    --with-gnu-ld \
    --enable-lto \
    --disable-nls

(...)
gcc/configure \
    --target=$TARGET \
    --prefix=$PREFIX \
    --enable-interwork \
    --enable-multilib \
    --enable-languages="c,c++" \
    --with-newlib \
    --with-gnu-as \
    --with-gnu-ld \
    --disable-shared
make all install

I've patched binutils to make it build for arm (header bug), and
patched newlib. The gcc patches only seem related to other arches, but
I tested both patched and unpatched, no good. I've also tested
gcc-4.4.2, it didn't work, same error:

arm-rtems4.10-eabi-gcc --pipe -DHAVE_CONFIG_H   -I..
-I../../cpukit/../../../gumstix/lib/include -D__RTEMS_INSIDE__
-mcpu=xscale -mstructure-size-boundary=8 -O2 -g -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-MT src/libsapi_a-posixapi.o -MD -MP -MF
src/.deps/libsapi_a-posixapi.Tpo -c -o src/libsapi_a-posixapi.o `test
-f 'src/posixapi.c' || echo
'../../../../../../source/rtems_trunk/c/src/../../cpukit/sapi/'`src/posixapi.c
In file included from
../../cpukit/../../../gumstix/lib/include/rtems/posix/barrier.h:80,
                 from
../../../../../../source/rtems_trunk/c/src/../../cpukit/sapi/src/posixapi.c:36:
../../cpukit/../../../gumstix/lib/include/rtems/posix/barrier.inl:65:
error: expected ‘)’ before ‘*’ token

..and the errors go on. This is pthread_barrier_t not being defined,
and gets fixed if I define _POSIX_THREADS on the Makefile (but other
errors arise).

The configure script in cpukit gives me this, which is suspicious:

checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_rwlock_t... no
checking for pthread_barrier_t... no
checking for pthread_spinlock_t... no

Any help is really appreciated. In the meantime, I guess I can test
with prebuilt RPMs..

Cheers,
  Renato

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