-icrossdir

Peter Naulls peter at chocky.org
Tue Dec 28 08:57:54 PST 2004


In message <3066.212.69.223.63.1104251489.squirrel at 212.69.223.63>
          "Nick Burrett" <nick at sqrt.co.uk> wrote:

> What's your intention then ? To create in UnixLib the same mess of a
> directory and build structure that is currently contained within glibc ? 
> Most of the mechanisms are redundant for UnixLib because we are targetting
> one operating system and one processor.

Whether it's a mess or not is probably a matter of opinion.  We
certainly don't need all of it.   Yes, it does add complexity, but IMO,
this is the very complexity we need in order to make Unixlib a more
comprehensive library.

> I don't see why we need to add the complexity of glibc to our C library.
> It affords us no real benefit.

I'm sure we already discussed this point in the past.  But ultimately,
it comes down to how much work is involved in maintaining it.  We've
spent a considerable period of time over the last three years tracking
down bugs because of incompatibilities with glibc (and other Unix C
libraries of course), missing functionality from various specifictions,
and just dumb bugs.  We've done a great job, certainly, but in places
we've hit a wall. The fnmatch stuff was an example of that.

> > My preference is to change as little glibc code as possible, since I
> > think this will ultimately save us a great deal of work.  This does mean
> > I will likely, at least in the short term, cause massive breakage in
> > Norcroft, and probably a load of extra warnings as I undo some of the
> > changes John has done to support RISC OS.  In the first instance, my
> > priority to update the older glibc files we have, and to have it at
> > least compile.
> 
> I think this may be a bad move, and where does it end ?  Are we next going
> to import glibc's stdio as well ?  

It will end where there is most benefit to RISC OS users.  I think you
are being flippant about stdio - clearly Unixlib's stdio implementation
is far and away the most crucial part of providing Unix compatibility in
RISC OS.

> I think it would be better to simply port glibc rather than try to put
> too much effort into converting UnixLib into glibc.

Having spent now this much time on it, there isn't really a big
difference between the those two goals in the short term.  It may
ultimately be that RISC OS uses a full port of glibc instead, but that
is some way off, and has many other implications.

Clearly this is a touchy issue.  I don't know what to say beyond that,
except I am doing what I think will best suit the long term goals of
bringing new software to RISC OS.  I know also that many of the changes
I'm making may be unpopular - clearly I'm going to break lots of things
in the short term, and am throwing away a fair amount of code that was
written for Unixlib by Nick and others, whilst trying to retain the bits
that are most important to RISC OS.

-- 
Peter Naulls - peter at chocky.org        | http://www.chocky.org/
----------------------------------------------------------------------------
Drobe - http://www.drobe.co.uk/        | The Premier RISC OS News Site



More information about the gcc mailing list