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

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

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

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.


To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: