matthew green <[EMAIL PROTECTED]> writes: > So, we have to decide whatever we use native libc, or port glibc? > I have faced some issues during my sysvinit port (it's about > 50% done, so hold on :), that required me changing NetBSD's libc > header files (for example, utmp.h). > So, let's decide, what are we going to use? > > > what did you have to change in utmp.h? that seems ... the wrong > thing to do. note that porting glibc includes all the machines > that netbsd runs on (currently 44, across 12 CPU architectures). > i don't think this will be an easy task. i'm sure that _in the > end_ you'll probably want to do this, but as it stands there are > probably better things to work on. libc is also highly tied to > the kernel, due to the implementation of system calls. note that > to avoid having libc's major number bumped, that many standard > system calls are "renamed" by header files, and that the real > (modern) syscall is actually something like __fstat13(). this > will require significant work, sometimes in MD code.
Indeed. I'd suggest that you'd be better off making a list of missing functions and asking Matt and myself to get them integrated into NetBSD's libc. It should be straightforward to do that. Perry -- Perry E. Metzger [EMAIL PROTECTED] -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/
