"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

The End of libc5: A Mini-Interview with H.J Lu

From The Answer Guy on 29 Jul 1998

H.J.
I hate to bother you with a more discussion on this topic. However, I'd like to have a definitive posting for the Linux Gazette (I do the Answer Guy column there) to allay people's concerns about this migration.

So, I'd like to ask a couple of questions:

Is there a definitive archive or document on the web that you feel accurately answers most questions about the glibc vs. libc 5 controversy?

No. I have posted a few articles from time to time. As far as I know, glibc 2 is very good now. The only problem it has is some Linux specific programs use the kernel header files directly. It won't work with glibc 2. We have to change those programs and we have to add those missing pieces to glibc 2 if necessary. So far, everything looks good. RedHat and Debian have built their entire Linux on glibc 2.

It is my impression that libc.5 and glibc can co-exist on a system concurrently and transparently. Is that so?

Yes.

Are there exceptional cases?

All those binaries compiled by egcs and gcc 2.7.2.3 should be ok. But if you have a C++ binary which uses libg++ and was compiled by gcc 2.7.x.x other than 2.7.2.3, it may load the wrong libg++.so. But I don't know if there is a case where you cannot recompile it.

I gather that a couple of the major advantages to glibc have to do with: support for NIS, thread-safe library calls, transparent support for the shadow password suite in the getpwent() and related functions, and much easier compatibility with other GNU sources (without requiring as much porting effort on the one side nor as much library maintenance by you, personally, on the other). Is that all true? Are there other compelling advantages to glibc over libc.5?

How about conforming all those standards, like ANSI C, POSIX, XOPEN and UNIX98?

I've heard complaints that glibc takes up significantly more disk space and run-time core (RAM). I've also heard

glibc is compiled with -g by default so it does take more disk space. The harddrive is cheap. I'd like to keep those debug info in library. In anycase, you can run strip on them. But I won't recommend it unless you are building a very small Linux installation. As for memory, glibc 2 has more stuff than libc 5. It has to bigger libc 5. I don't call it libc 6 if it is smaller than libc 5. But Unix has demand paging. Those unused portions won't be loaded into memory anyway.

that running 'strip' on it can significantly reduce its disk footprint. Where can I find a more comprehensive comparison of the speed, disk space and memory requirements of the two sets of libraries?

We have to pay the price on speed and size for a MT-safe C library. But there are so many new optimizations in glibc 2. I would say glibc 2 is faster than libc 5. As for disk space, it depends on if you want to run strip or it. By default, glibc 2 provides much more debug info than libc 5. With libc 5, when something goes wrong with the C library, I have to use a speciial C library just to debug it. With glibc 2, I just run gdb on the binary compiled with -g. As for memory requirement, I believe it is the similar to libc 5.

I presume that someone else could (if they wanted) take up the maintenance and continue to improve libc.5 (in the spirit of the GPL) if they really wanted to do so. Is there

Sure. Anyone is free to do so.

any argument you would present to, or question you would ask of someone who was proposing to do this?

libc 5 is quite stable. Most of the fixable bugs are fixed. All the new developments have gone to glibc 2. glibc 2 also has fixed those bugs which are hard to fix in libc 5. I don't see why we should spend more time on libc 5.

Last one:

Now that you're free of libc.5, are there any projects that you are particularly interested in pursuing (open source or otherwise)?

I have been working on egcs/gcc, binutils and gdb for Linux. I will keep doing so. In the meantime, I am very interetsed in projects using C++, thread and distributed technology, something like CORBA. I have been thinking a new paradigm for Unix. Instead of a C or C++ library, we use something on the line of CORBA or DCOM.

Another thing, every program is compiled with -fPIC as a shared library, i.e.:

# gcc -shared -o ls.so -fPIC ls.c ......
# gcc -o ls ls.so

Now, we have both ls and ls.so. Another program can do

int (*ls_main) (int, char **);
void *handle;

handle = dlopen ("ls.so", ...);
ls_main = dlsym (handle, "main");
ls_main (argc, argv);

We can also use it instead of expensive

isystem ("ls");

It can go with the CORBA/COM idea. That is we define an object oriented interface for a service, which can be a local shared library or a different process which can be local or remote.

With your permission I'd like to submit your answers for possible publication in next month's Linux Gazette (whichi is available online and distributed under the terms of the LDP GPL). Please feel to add any comments you like to your response, (or to tell me to buzz off for that matter).

It is fine with me.

Regardless of your response I'd like to personally express my gratitude for all the work you've done for Linux over these last few years. If you're ever in the SF Bay Area,

---

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 32 September 1998

---

	phreak	abandon	javaterm	BBS	flaws	doslinux	resume
	softwindows	convert	apache	emulate	database	distrib	proxy
	disable	DVI	superblock	serial	permission	detach	cdr
rs422	modem	notfound	tuning	libc5	startup	clock	ping
accounts	lilo	NDS	95slow	nonlinux	progenv	cluster	ftpd

---