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