This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: sys/types.h is broken for _POSIX_THREADS
On Wed, Feb 24, 2010 at 2:47 PM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
> 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.
Aparently the problem was that I was using an arm-rtems4.10-eabi
target.. Using an arm-rtems4.10 target seemed to fix things (strange).
I'm not sure where's the problem, but it may be related to the
autoconf scripts. I built the toolchain using a two-stage-gcc
compilation, and it still worked. Conclusion: don't use an eabi target
:)
> (...)
> 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.
I'll use the yum repos from now on, thanks for your help!
Cheers,
Renato
> --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
>
>
>