The ebuild is called dev-util/lafilefixer, and to run it:

lafilefixer --justfixit

Whoever put this together has now helped me a great deal… I had literally hundreds of .la files that it updated. Plus it fixed amarok and let me complete my emerge update.

I wish they were kidding. Please, let that be a joke.

How did this happen?  Because my /var/lib/portage/world file has a lot of packages in it that don’t really need to be there (they should be pulled in as dependancies of packages I do want, not in the way I have them.)   When I was migrating to the this box, instead of just looking at the few hundred packages in world, I grabbed a list of everything I’d compiled, and used that to build my new box.   One result of that is that sys-libs/libselinux got compiled.  (At least, I think that’s how it happened.)   I noticed but didn’t think it was going to be a problem.  However, for some ebuilds (coreutils being the most important to me), if the selinux header files are installed on the box, the configure script detects files like /usr/include/selinux/flask.h and proceeds to include selinux support.   Then you will find that /bin/cp and many other critical utilities are linked against libselinux.so.1, so you can’t remove the sys-libs/libselinux, and since the USE flag has no effect other than changing RDEPEND in the ebuild, you’re stuck.   Catch-22, almost.

Today I finally resolved to fix this, because I got annoyed, and because sys-libs/libselinux is hard-masked after my latest sync (as a result of the sync and having to update my profile with eselect).

The first part, fixing coreutils is pretty easy:

euse -D selinux
mv /usr/include/selinux /usr/include/selinux-save
emerge -av coreutils
emerge -C libselinux
rm -r /usr/include/selinux-save

Unfortunately, after that… you are still stuck.   The coreutils will work, but I was left with a number of packages that revdep-rebuild reports as missing libselinux.so.1… furthermore they all die when trying to link against libselinux:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lselinux

Ah, portage, why are you so cruel to me?    The above example is from gnome-terminal.  Good thing I still use xterm.

Note: the next part could help, but it’s far easier to use lafilefixer these days.

So, what to do?   I’m not kidding, this is basically it, in one line form:

find /usr/lib64 -name '*.la' -print | xargs grep selinux | cut -f1 -d: | sed -e 's#^./##g' | xargs equery b | awk '{print "="$1}' | sort -u | xargs emerge

Built that up once I realized that the *.la files still contained references to the libselinux (-lselinux).  Basically, it searches for all the .la files that contain references to selinux.   .la files are just text files that control the linking process, either as part of libtool or the compile-time linker. My command above just uses some rather lame shell tricks to run emerge against all the packages those files belong too.

Even after that was complete, I still had libnss3.so.12 breakage to contend with, but at least revdep-rebuild was working at that point (not breaking on every ebuild it found missing libselinux.so.1).    Frustrating.

I hope this saves someone some damn time, somewhere.

This actually seems legit to me, in all the particulars.  I want it to be true, anyway.

So… I backed off that plan and installed a pair of 120GB drives.  Now the system won’t boot.  And the console is, shall we say, unresponsive. I live a charmed life, I tell ya.

As a result, I have since collected a couple of other old Sun workstations via Ebay and the employee purchase program at work (which are basically “worthless”, like $65), and even an old Pentium 4 for Solaris x86.   So I’ve got the gear, but I haven’t had time to continue with any but the most cursory examinations of OpenSolaris.   I got 2 of them booted up with ZFS root on fairly recent versions of Nevada.   Waiting for the SPARC release of Indiana to be readily available.

In the meantime, I thought I might work on some of my other Solaris related projects.

One suggestion I keep running across in my normal google searches is to disable HWCursor in xorg.conf.   Messed around with that for a few days.

After a lot of tests, it turns out that killing xscreensaver fixes the problem…. no need to restart X.

Lately, the problem has stopped happening, so I am considering that an update to x11-misc/xscreensaver may have fixed the problem.

The first problem is that libraries are no longer found along their proper paths…. libc.so is the first problem. That’s easily fixed, however.

# export LD_LIBRARY_PATH=/cores/usr/lib:/cores/lib

That’s the simple part, I’m sure most people know the LD_LIBRARY_PATH tricks to force searching for libraries in other directories. The part that I don’t think people get is… once you’ve done that “ld.so.1″ (the runtime linker) is still in the wrong place. ld.so.1 is responsible for using the LD_* variables in the first place, among the many other wonderful things it does. So running commands from, for example, /cores/usr/bin is still impossible, at least in the standard way.

The second and final trick you need to fix this is to use ld.so.1 to “run” the executable. So, this fails:

# /cores/usr/bin/mv /cores/* /
mv: Cannot find /usr/lib/ld.so.1
Killed

But this allows you to run a command like you’d expect:

/cores/usr/lib/ld.so.1 /cores/usr/bin/mv /cores/* /

Turns out, you can use “ld.so.1″ as an “interpreter” of sorts for executables on some flavors of Unix. At least Solaris and Linux, but I would not be surprised if this works elsewhere, I simply haven’t tested it. On Linux, for example, you would use something like:

/lib/ld-linux.so.2 /bin/ls

To run “ls” in this fashion.

The lesson, boys and girls, is to know your runtime linker, it may save you one day.

Oh, and not to spoil it for anyone, but the weapons the various military units had available (even conventional) should have turned the big monster into something the consistency of paste, unless it had some unseen and unexplained powers. I mean seriously, they hit it with a lot of ordnance. Once you’ve decide it’s ok to drop bombs on your own city, that opens up a lot of options. That B-2 Spirit alone cares 20 2,000 pound bombs… I mention it because they show a bomb run that gets a couple of direct hits. And then I was wondering why they hadn’t napalmed it yet.

I realize that normally I’d be expected to suspend disbelief (it’s a monster movie, after all), and I would… but going back to my first point with the shaky camera, once I get a bit annoyed at a film, I start to pick it apart. I feel bad about it, but I do it anyway. In other words, giving me a bit of a headache does nothing for my enjoyment of the movie.

I think other than the headache it was an interesting piece of work. I hope they do another one without the hand-held camera, while somehow preserving some of the better aspects. Just so they can explain some things, if nothing else.