Ok, picking up where I left off last night, I set up all the necessary symlinks and installed my fresh glibc2. Compiling a small c program and checking it with ldd, I verified that my compiler (still gcc-2.7.2.1) was indeed now linked to glibc. I left libc5 and libm5 in /lib, just so the few things I had built against libc5 (binaries from my "Minimal" install) wouldn't be broken, until I was sure I could live completely libc5-free. Everything I was building from this point on was glibc, but I still had X and the bare necessities linked against libc5. I built a fresh kernel, rebuilt some of the basics now with glibc like bash and things I would need for compiling stuff (bison, flex, make, guile, termcap, blah ad infinitum; I essentially compiled stuff all day long), and built egcs-1.0.3a. All of this went off without a hitch, so I booted my fresh kernel. Everything came back on line, I verified the versions of all the programs I had compiled under glibc, and oddly enough I wasn't running into any problems. None. I set up networking and spent a brief time doing everyday stuff like web browsing and irc. I spent some more time compiling libs and apps, and I've come to some conclusions. Originally my intention was to produce a 100 0libc based system. A) That is a really ambitious project, and it makes you appreciate the work the people at SuSE, RedHat, Debian, Stampede, etc. do. B) The more I worked in my new glibc based system I saw no reason to eliminate libc5. The integration between my newly built glibc based apps and libs and my existing libc5 based apps and libs was pretty seamless. C) I noticed that some things that built fine under SuSE 5.2 didn't build under SuSE 5.2g. This was consistent with my brief RedHat 5.0 experience (Donnie, you know I don't mean that as an assault on RedHat, so don't get bent ;) ). I am not discounting operator error by any means, but regardless, I feel that glibc DOES choke on some source code that doesn't pose problems for libc5. In all fairness, this is probably because the development boxes were libc5 based, much the same way that Gnome doesn't like libc5 much because it is being developed (primarily) on glibc (although I saw one Gnome developer proclaim on the Gnome mailing list that he uses a libc5 box for development). D) Gnome _does_build_better_ in a glibc environment, but a couple of packages still gave my box the hiccups. I had as much luck getting mc to compile in glibc as I did in libc5. Is Gnome ready for the desktops of America's linux users? Not really. Is Gnome something we should all be keeping a watchful eye on? You bet. I think it's a popular misconception to think of Gnome as a gtk-based kde. This is developing technology (gnome and gtk) that is window manager independent and in the case of gtk we have a rapidly maturing interface that in time will allow the user to custom tailor the look to a degree that motif and qt simply aren't capable of. I was really surprised how painless the whole glibc thing was. I expected several days and many set backs getting things functioning. What I didn't expect was how peacefully libc5 would coexist with glibc. I could spend several more days converting to a solely glibc based system, but I don't really see the point now. I am going to reformat, do my regular SuSE install and then install glibc as a secondary c library so that I can link it for apps that, well who am I kidding, so I can keep compiling Gnome snapshots ;). But I am going to keep libc5 as my primary c library, because, for now, it seems to be more reliable/predictable for compiling source, something we all do a lot of. I'll let you know if I run into any problems, any apps or libs getting broken somehow, but libc5 and glibc seem to do all right together, something I wouldn't have expected. -- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e