Re: Dependancies on libc
> > I'm also thinking about porting glibc to *BSD. I think that would
> > solve very much problems, as a lot of programs just expect to have
> > glibc installed. A lot of kernel-specific things are already fixed
> > because we want them to compile on Debian GNU/Hurd. But the Hurd also
> > uses glibc, I expect really much trouble with that. Most people just
> > don't know how to write portable or don't care about it. I don't know
> > if I'm the only one thinking about porting glibc.
> Feel free. I looked at it, and I think I'd rather spend my time
> elsewhere. It would be a huge help, though. Even if you're successful, I
> think we'll need to have the BSD libc available for the kernel specific
Well, porting GNU libc is definitely a Nice Thing(tm). The question is, will we
want to use it? There are certainly people who think that one of the main
attractions of a BSD is the sleeker, not-so-bloaty C library. Now, coexistence
is certainly not the problem... the question is, which C libraries do programs
use, and how much choice are we offering? Would the majority of packages be
binary compatible? (/etc/alternatives/libc.a, anyone? :) Or would we have to
fork into two architectures if we wanted to offer a choice, e.g.
netbsd-i386-glibc and netbsd-i386-bsdlibc?
Maybe we'll have to use NetBSD's linux emul after all?
> As for portable code, I think that's something that needs to change.
> Portable code tends to be better code. I'd rather see some of the Debian
> tools like apt become more portable than have a glibc port, because I
> think making those programs more portable will most likely improve them.
I second this motion. :)
-----BEGIN GEEK CODE BLOCK-----
GCS/MU d- s+:+ a--- C++ ULISBH+++ P+++ L++(-) E-
W--(+) N o? K? w--- !O !M V?> PS+++ !PE Y+ PGP-
t+(-) 5 X R+>+++ tv-- b++ DI(+) D G e->+++ h r-- y
------END GEEK CODE BLOCK------
Do You Yahoo!?
Send your FREE holiday greetings online!