sys/types.h is broken for _POSIX_THREADS

[Joel Sherrill]

On 02/24/2010 04:03 AM, Renato Caldas wrote:
> 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 :)
>    
I am on Fedora 12 and that's even that the virtual machine
for potential Google Summer of Code students will be.
The RTEMS Project is better able to support students on
Fedora.  Besides this is free software and we encourage the
use of other free software.
>    
>> 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
>
>    
Ahhh.. procedural and patch problems. :-D

I will give you some pointers and then let's move
this to the rtems-users mailing list since this is more
an RTEMS issue.

When you check out RTEMS from CVS, look in
contrib/crossrpms/patches.  These are the current
patches which must be applied.  It is possible that
binutils 2.20 may not have one.

We build newlib as part of the gcc build.  Symlink
or move the newlib directory into the gcc tree.

The scripts I use to build gcc svn and test it are
in the RTEMS CVS module gcc-testing.  That will
have all the commands after the patched tree is
setup.

But since you are on Fedora, use our RPMs.  It is
easier.  We have a Yum repository and even now
have drpms so you can use presto and save download
bandwidth on updates.

--joel
> 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
>>
>>
>>
>>      


-- 
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