I’ve put this off for a long time, but I’m finally rebuilding my desktop from scratch. Actually, my one at work, too. Today is a state holiday here in Utah, and it’s great taking a day off in the middle of the week. I honestly have no idea what time it even is right now.

Anyway, at home my box is a dual-core AMD Athlon64 something or other. I’ve stopped building boxes a while ago after realizing that while it may be only around $300 to get started, it ends up costing another $400 for all the stuff I really wanna get on there, like a decent video card and quiet power supply, so this has been my box for a while. In fact, I’m running the exact same motherboard in my media server as well. It’s actually really nice knowing that I can swap hardware between the two boxes in a pinch (which has already happened) without worrying about the specs.

This box has been doing great, and I really don’t use it for much more than just surfing the web, writing email and of course Gentoo development. I’ve had problems on and off with XFCE and X. Exiting out would kill all input, and I could never figure out the cause. It wouldn’t matter which video driver or video card I used, so I just worked around it — I’d switch to the shell if I wanted to kill X, instead of just logging out, etc. But, one thing I sorely miss is using tuxonice, so today I finally decided to take the plunge and scratch it all.

It has been a long time coming, too. I can’t even remember the last time I installed the system on here. Generally speaking, I usually reinstall anyway just to clear out cruft and what not about every 18 months or so. It’s also a good way to keep me on my toes with new installs — my biggest problem is *still* forgetting to change my root password from a fresh stage3 install.

I’ve gotten pretty far, as I’m writing this in Seamonkey right now, and I started this morning. I’ve already been going through the list of stuff I had installed and it’s amazing how many applications I try out and then completely forget about. I’m actually excited to try out the new jobs and resume options in portage, see how that changes things around.

Actually, the thing that kicked off the reinstall at home was that I finally broke down and decided to do my one at work, first. The box is also a dual-core 64-bit machine, but it’s an Intel Pentium D. Now, for some reason, I have *never* had much luck with any of the Intel boxes. I always have some stupid problem where they just end up unresponsive for some reason that I’ve never had on the AMD boxes. I’ve never been able to pin it down, and so I’ve been methodically getting rid of any Intel-based boxes I have around.

This one at work is particularly painful though, though it’s mostly my fault. It’s only got 512 megs of RAM in there which is the obvious bottleneck in today’s modern desktop scenario — especially for a Linux workstation like mine where running a dozen applications all at once is the norm. At first I tried to resist doing anything about it so I changed my CFLAGS to -Os to save on memory (which I probably should have done in the first place), and while that helped, everything of course slowed down by a huge magnitude. Still, at least I wasn’t having jerkiness — it just took everything twice as long to load and save.

I finally broke down this week and shelled out $50 to buy 2 gigs of RAM for the machine. I haven’t been watching computer prices at all recently, so I was quite surprised by how cheap it was. In fact, I’m tempted to put more in my box at home. I’m sure that’ll fix things up alright. In the meantime, it’s reinstalling right now, chugging along, and seeming to do fine. I think I needed my head cleared of all the crap more than that box did, really. Sometimes, even though we technically don’t need to reinstall, it’s just a good mental relief knowing that you’ve done everything you can to make things run better. That’s a hard belief to argue against.

One thing I also did on my box at home is I finally switched over to ~amd64. I’m running unstable, which may not seem that big of a deal, but my policy over the last six years or so of using Gentoo, on my desktop at least, was to use the stable tree. Slowly, though, one by one, on all my other boxes, I’d switch them over to unstable and just run that tree, and I found that more often than not, it runs just fine without a hitch. I first switched over with my myth box, when I realized that my package.keywords file was longer than my arm — if there was one thing I always wanted the very latest bleeding edge code of, it was all the bugfixes and improvements for the multimedia software. The myth box is an obvious choice, and even then, you get it to a working point and then just leave it alone for an eternity. Those last two sentences just contradicted each other, I realize, but anyway, the point was — well, I forget.

Ooh, this –jobs option is pretty cool. Good work, Zack. Gentoo rocks, what more can I say.  After all this time, I’m still a fan.

After my previous post about preserved-libs feature, I was asked by many users if I was against this feature because it incremented the usability of Gentoo. I sincerely think I shown before that I don’t want Gentoo to remain for elitists, and thus I won’t be going to say nay to anything to make stuff easier to the users.

On the other hand, I want to make sure that users, excited about being able to upgrade stuff without breaking their system, won’t break it even further. For this reason I want to warn again users against trying the unstable Portage version (2.2) on their stable systems just yet.

Thanks to Zac and Marius, the problem I’m going to talk about is already being taken care of, so it won’t appear once 2.2 final will arrive. So why am I writing about this anyway? Well the reason is actually quite simple: future memory.

On the topic of linking, loaders, ELF files and all the things related, there isn’t a lot of documentation that is available to newcomers. Most of it is very technical and requires good knowledge of many concepts to be useful. I only know of a book that goes in deep of this, Rob Levine’s Linkers and Loaders is probably the most interesting reading on the subject ,as far as I can see. Unfortunately I haven’t tried converting the downloadable version in LRF to load it on the EBook Reader and I haven’t got the printed copy. I should probably get that too, as a reference, I’m just afraid that all the hardcopies I have here will remain at my parents’ house once I move out.

Okay, let’s return back on topic now. What is the problem I found today with preserved-libs? Well as I updated to Xorg 1.5 pre-releases to check if my RandR problems were fixed (by the way, they are), there was a libGL update. I also took the time to switch back to gcc 4.2 for a short time as I wanted to rebuild VirtualBox without ALSA support (whenever I can I’m using PulseAudio), and I could also rebuild xmlrpc-c (the reason why I couldn’t build this with GCC 4.3 is good for a different entry one day). After these builds, Portage told me this:

!!! existing preserved libs:
>>> package: media-libs/mesa-7.1_rc3
 *  - /usr/lib64/libGLU.so.1.3
 *  - /usr/lib64/libGLU.so.1.3.070003
>>> package: dev-libs/xmlrpc-c-1.06.27
 *  - /usr/lib64/libxmlrpc.so.3.6.4

I was surprised because I know libGLU rarely changes interface, and I didn’t think xmlrpc-c would have either. And indeed a quick scanelf run over the files confirmed my ideas:

flame@enterprise ~ % scanelf -S /usr/lib64/libGLU.so*
 TYPE   SONAME FILE 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3.070003 
ET_DYN libGLU.so.1 /usr/lib64/libGLU.so.1.3.070100 
flame@enterprise ~ % scanelf -S /usr/lib64/libxmlrpc.so*
 TYPE   SONAME FILE 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3.6.15 
ET_DYN libxmlrpc.so.3 /usr/lib64/libxmlrpc.so.3.6.4 

As you can see the soname for both the versions of libGLU and both the versions of libxmlrpc is the same. So there is no ABI break, and no good reason for the file to disappear, right?

Indeed if we focus solely on the xmlrpc-c case, the result of preserved-libs actions is that there is now an orphaned unused and unusable shared object:

flame@enterprise ~ % ls -l /usr/lib64/libxmlrpc.so*    
lrwxrwxrwx 1 root root    19 2008-07-22 18:04 /usr/lib64/libxmlrpc.so -> libxmlrpc.so.3.6.15
lrwxrwxrwx 1 root root    19 2008-07-22 18:04 /usr/lib64/libxmlrpc.so.3 -> libxmlrpc.so.3.6.15
-rwxr-xr-x 1 root root 56864 2008-07-22 18:04 /usr/lib64/libxmlrpc.so.3.6.15
-rwxr-xr-x 1 root root 56368 2008-02-23 13:36 /usr/lib64/libxmlrpc.so.3.6.4

Let’s see, ld.so (the runtime linker) will look for a library with, as filename, the soname listed in a program’s NEEDED entry in the dynamic seciton of the ELF file. In this case, the soname of libxmlrpc is libxmlrpc.so.3 so that’s what the linker will look for. On my system, that filename is linked to the 3.6.15 version, so the runtime linker will always load the new version of libxmlrpc. The build-time linker (ld) looks instead for the filename with the simple .so prefix (or .a for static libraries). That one is also pointing to 3.6.15.

So who is using the 3.6.4 version that Portage preserved? Well, the only way to use it is to dlopen() it directly and accessing it that way. Which, if anything would be doing that, would be craziness, to the point that I’d rather not see such a software in my system at all. The other option is for an ELF file to have a tweaked NEEDED entry that points explicitly to the full version, but I can tell you I have none of those.

So for now I’ll simply remove the two files, and get rid of the problem. But as you can see, it’s too soon to expect preserve-libs to work out of the box in a perfect manner.

Anyway, Marius, Zac, please keep up with the good work, it’s really needed :) Thanks guys!

For those of you who’d like to follow Google Summer of Code progress (I’d very much like to have the blogs of the student available on Universe by the way), today (or rather yesterday) can be counted in as a very important date :)

Seraphim prepared a patch for shadow (the package containing all the basic utilities for users management in Linux) to work with OpenPAM, rather than depending strictly on Linux-PAM. I committed it in tree now for 4.1.2.1 and upstream applied it to trunk already, so now it can be built even when using OpenPAM rather than Linux-PAM. Cool, eh?

This patch (and the related bug) are important not only because they fix a very important part of the functionality of a Linux system with OpenPAM, but also because it will act as a base reference to fix other software to use OpenPAM too.

Indeed, one of the most obnoxious problems with OpenPAM is that a lot of packages instead of writing their own conversation functions rely on misc_conv. Seraphim prepared a patch that can be applied to almost any other package relying on that to make it OpenPAM-compatible. It’s very good.

Unfortunately, as Seraphim also blogged there is one catch with being able to provide OpenPAM support, especially for the future. The problem is that although mostly API compatible, OpenPAM and Linux-PAM are not ABI compatible. Although in a very subtle way, because, as Seraphim learnt, you can have a system built against Linux-PAM run against OpenPAM just fine, up to a point.

The problem is that ABI does not only refer to the name of the functions, or the type of their parameters, but also to the meaning of flag values. In this case, Linux-PAM and OpenPAM give different flags different meanings, so modules built against OpenPAM will not work properly with software built against Linux-PAM.

This is going to be tricky, especially once we’ll allow users to switch from one to the other and vice-versa, because it means all the software will have to be rebuilt to continue functioning as it’s supposed to. And no preserved-rebuild will help us there.

Oh well, there’s time to think of that!