Re: Glibc and NetBSD
Ian Jackson wrote:
This whole conversation seems baffling to me. Have any of the people
posting opinions actually looked at the source code of the two libcs ?
I have. I've done some hacking on both the FreeBSD libc and glibc.
glibc is a complex horror [1]; the BSD libc is a fairly nice and clean
implementation. It seems to me that there is little doubt which libc
we would prefer if we want good code quality.
glibc tries to do a lot more than the BSD libc. Amongst other things,
it's intended to be portable to more than one kernel (originally it
seems they had it working on several), and seems to succeed fairly well
at that. The FreeBSD port of glibc turns out to be simpler that it
looked to me at first, because I didn't understand how glibc is structured.
I would assert that any large body of source code that tries to be
portable, reasonably backwards compatible, and standards compliant will
probably become complex or ugly looking. Think you could port BSD libc
to Linux without making a mess?
As for your footnote: I believe that had to do with Linux getting
switched to a newer implementation of stdio, while the Hurd stayed with
the old one for a while. The old one will probably get removed soon, as
I believe the Hurd now has switched as well. So it was a temporary
situation.
Also, nearly all of the programs in Debian are _supposed_ to be
portable to BSD anyway, at least upstream. Pretty much anything that
doesn't work is either a bug in the Debian package, or in the BSD
libc.
That's a severe oversimplification. A large number of packages in Debian
aren't really very portable off of Linux. Code written for Debian is
often the worst, as much of it assumes glibc and/or Linux. base-passwd
or debianutils are typical examples.
I understand that the i18n facilities in the BSD libc are not
currently adequate or working and that this is a considerable problem.
This is of course a bug in the BSD libc, but surely we can just punt
on it by supplying a bunch of stub routines ? Debian GNU/BSD won't
have i18n then of course until the BSD libc is sorted out, but that
seems fair enough. If i18n people don't like that they can go and
work on the BSD libc.
Bear in mind, that we have most of the i18n stuff already, in libintl
and libiconv. Let's look at the sizes of these libraries on the Debian
FreeBSD system using libc, and compare against glibc:
libc.so.4
674512
libiconv.so.2
864360
libintl.so.1
31381
total
1570253
glibc:
libc.so.6
1156644
You might want to think about that.
Some things, like NSS, simply aren't there in BSD libc. There are also
things that are there, but aren't usable on Debian, like the ancient
utmp, and incompatible passwd and shadow support.
The BSD libc is smaller for about the same reason that dietlibc or uLibc
on Linux are smaller. Those libc's don't attempt to be portable (across
kernels), and they certainly don't attempt to comply with all the
standards that glibc does.
---Nathan
--
To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: