GCC development status 2002-12-15
nick at dsvr.net
Mon Dec 16 02:07:49 PST 2002
John Tytgat wrote:
> In message <3DFC9145.7060406 at dsvr.net>
> Nick Burrett <nick at dsvr.net> wrote:
>>I've committed Alex Waugh's patched for 'pthreads' and stack-chunks and
>>the 'riscosify' to the CVS trunk. John Tytgat's resolver library
>>re-working will also appear soon. I feel that these patches are too
>>invasive to be committed to the 2.95 stable branch. I think that we
>>should be able to iron out most of the bugs during the 3.3 development
>>phase, especially considering the other UnixLib work that's required.
> For the resolver library work I took the approach to take over the src
> & header file organisation & code of glibc. I realise now I haven't asked
> the feedback from the other GCC/UnixLib hackers to backup this decision.
I'm thinking of cleaning up a little bit of stuff in the source files
and header files, then committing it.
> Do we agree this is a good approach and will we continue doing this ? The
> more closely we can follow the glibc structure and code, the easier we
> can introduce new features, no ?
I fear that we'll end up with a hugely bloated and very slow C library.
I prefer to clean up the header files and source files to remove the
portability code that is largely irrelevant on RISC OS. Certainly we
don't have to support the range of legacy compilers and a wide variety
of operating systems.
Though this might make the effort required much greater, I feel that the
long term benefits are simpler maintenance.
An alternative approach would be to take the base UnixLib and then work
on porting GLIBC to run on top of it. I started a project on this
several years ago but got overwhelmed by the complexity of the header files.
Network Engineer, Designer Servers Ltd. http://www.dsvr.co.uk
More information about the gcc