Re: problems compiling gcc-3.3.5 with newlib-1.12.0

[Matthew J Fletcher <mfletcher at serck-controls dot co dot uk>]

On Monday 17 Jan 2005 3:55 pm, Dan Kegel wrote:
> > However my troubles seem to have increased. It appears
> > that what is required is posix thread support (the
> > same as that provided by the glibc-linuxthreads
> > library ). On checking the configure options for
> > newlib-1.13.0  I find that --enable-newlib-multithread
> > apparently enables support for multiple theads. Also
> > on compiling  newlib with this option i get a
> > pthread.h header in $prefix/arm-elf/include which
> > (apparently - i havent checked fully) defines the
> > thread function headers. However on then trying to
> > compile the full gcc (with --enable-threads=posix) [fails.] ...
> > I'm still working on this but any inputs here would be
> > most welcome as from what info ive found so far
> > indicates that newlib does not support pthreads !
>
> I have no experience with newlib, so I can't comment.
> (But the --enable-newlib-multithread option seems to be a funny
> beast.  I don't know what it does, but judging from what's
> in newlib's source tree, I see a copy of linuxthreads,
> so I bet pthread support in newlib is a nasty hack
> that only works when you're building newlib programs
> to run on x86 linux!)

--enable-newlib-multithread will NOT define __SINGLE_THREAD__ if you search 
for that in newlib you will find that you need to implement (if your not 
using linuxthreads etc) the locking functions in lock.h. (i have attached my 
modified header file, as by default it will just compile empty functions).

if you doing to use a multi-thead newlib then you may want to define (for 
options passed when compiling newlib files)

-D__DYNAMIC_REENT__ and -DREENTRANT_SYSCALLS_PROVIDED

and then implement 'struct _reent * __getreent (void)'
and

void *_sbrk_r(struct _reent *REENT, long int INCR)
_ssize_t _read_r(struct _reent *REENT, int FD, void *BUF, size_t CNT)
 etc.

if you want to use c++ exceptions you have to tell gcc what thread model your 
using as well, but thats a seperate mail.

> The arm-elf target is not a Linux target, so the Linux headers
> are not required.  arm-elf is a bare metal target, no OS, I think.

correct, arm-elf (or properly arm-unknown-elf) and i[3456]86-elf (or properly 
i[3456]86-unknown-elf) are bare metal targets that haveno spesific support 
within gcc/newlib.


regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---

**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050   Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com  Admin: post@serck-controls.co.uk
A subsidiary of Serck Controls Pty. Ltd. Reg. in England No. 4353634
**********************************************************************
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.


This message has been checked by MessageLabs
******************************************************************

#ifndef __SYS_LOCK_H__
#define __SYS_LOCK_H__

#ifdef __SINGLE_THREAD__

/* dummy lock routines for single-threaded aps */

typedef int _LOCK_T;
typedef int _LOCK_RECURSIVE_T;

#define __LOCK_INIT(class,lock) static int lock = 0;
#define __LOCK_INIT_RECURSIVE(class,lock) static int lock = 0;
#define __lock_init(lock) {}
#define __lock_init_recursive(lock) {}
#define __lock_close(lock) {}
#define __lock_close_recursive(lock) {}
#define __lock_acquire(lock) {}
#define __lock_acquire_recursive(lock) {}
#define __lock_try_acquire(lock) {}
#define __lock_try_acquire_recursive(lock) {}
#define __lock_release(lock) {}
#define __lock_release_recursive(lock) {}

#else // #ifndef __SINGLE_THREAD__

/* externed lock routines for multi-threaded apps doing custom implementations */

typedef void * _LOCK_T;
typedef void * _LOCK_RECURSIVE_T;

#define __LOCK_INIT(CLASS,NAME) CLASS _LOCK_T NAME; \
 __local_lock_init(&NAME);
#define __LOCK_INIT_RECURSIVE(CLASS,NAME) CLASS _LOCK_RECURSIVE_T NAME; \
 __local_lock_init_recursive(&NAME);

extern void __local_lock_init(_LOCK_T lock);
#define __lock_init(NAME) __local_lock_init(&(NAME));
extern void __local_lock_init_recursive(_LOCK_T lock);
#define __lock_init_recursive(NAME) __local_lock_init_recursive(&(NAME));

extern void __local_lock_close(_LOCK_T lock);
#define __lock_close(NAME) __local_lock_close(&(NAME));
extern void __lock_close_recursive(_LOCK_T lock);
#define __lock_close_recursive(NAME) __local_lock_close_recursive(&(NAME));

extern void __lock_acquire(_LOCK_T lock);
#define __lock_acquire(NAME) __local_lock_acquire(&(NAME));
extern void __lock_acquire_recursive(_LOCK_T lock);
#define __lock_acquire_recursive(NAME) __local_lock_acquire_recursive(&(NAME));

extern int __lock_try_acquire(_LOCK_T lock);
#define __lock_try_acquire(NAME) __local_lock_try_acquire(&(NAME));
extern int __lock_try_acquire_recursive(_LOCK_T lock);
#define __lock_try_acquire_recursive(NAME) __local_lock_try_acquire_recursive(&(NAME));

extern void __lock_release(_LOCK_T lock);
#define __lock_release(NAME) __local_lock_release(&(NAME));
extern void __lock_release_recursive(_LOCK_T lock);
#define __lock_release_recursive(NAME) __local_lock_release_recursive(&(NAME));

#endif

#endif /* __SYS_LOCK_H__ */

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com