[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BSD libc or Glibc?

There are changes that would need to go in for utmp. Those affects sysvinit,
and the who program in the shellutils. Probably some other packages as well.

I had more problems with a handful of packages that were written for Debian,
because they assume that all of the libiberty functions are in the libc.

And there is the issue with ldd not working on shared libraries. This I found
on FreeBSD. I looked at the CVS for NetBSD, and it looks like it works
differently, so it's probably not affected.

There are three options:
	1. Get the needed functionality into the BSD libc.
	2. Patch the Debian package to not need it, or workaround.
	3. Port glibc.

I've been looking at glibc, and at this point, I'm in favour of the first two
options. Not because I think one libc or the other is better, but because it's
less work.

On Thu, Jul 26, 2001 at 11:01:27AM -0400, Perry E. Metzger wrote:
> matthew green <mrg@eterna.com.au> 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		perry@wasabisystems.com
> --
> NetBSD Development, Support & CDs. http://www.wasabisystems.com/
> --  
> To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: