Yuck: Undefined symbol "__sbmaskrune"

I have saved tons of compile time in the past by using updated 6-STABLE binary packages, even though I'm running 6.2-RELEASE. (As discussed in past articles here and here.) Well, the last couple of days I gave some of that time back. :/ Packages grabbed from the '/packages-6-stable/' subdirectory are not running for me in 6.2-RELEASE. They would mostly exit immediately with an error message something like this:

/libexec/ld-elf.so.1: bash: Undefined symbol "__sbmaskrune"

Everything worked fine again when I reinstalled those ports by compiling instead of using packages. So, I've gotten all upgraded, it just took a little longer.

It's not really uncommon to have occasional little library problems with the binary packages. Usually that's a minor thing related to one of the dependencies and easily remedied, often by compiling it instead. I'm not sure what's going on in the above case. I'd guess something about system libraries changing in 6-STABLE and the upcoming 6.3.*

Also, I noticed that I'm not alone with this issue. I've seen a couple of related questions on the freebsd-questions mail list (search for "__sbmaskrune") and one of those involved system files. (Whereas, I sort of had the problem in reverse, having 6-STABLE packages that wouldn't run on 6.2.) It's a good time to remember that any STABLE branch is really a development branch and may have issues, however rare.

* Update

This sort of thing isn't supposed to happen, of course. "uunixuser" commenting at bsdforums.org pointed out this commit message which seems to be fixing and backing out the problem.

Update 2

Just to clarify what the problem is(/was): There was a commit that changes some system libraries used by pretty much everything. So that ports compiled on 6-PRE-OOPS would no longer run on 6-OOPS, and vice-versa! My issue was I downloaded 6-OOPS packages and installed them on my 6.2 system. They wouldn't run. Most other people upgraded to 6-OOPS and then suddenly their old ports would not run. Now, the OOPS has been backed out and mappings for the OOPS library changes have been left in, so that a 6-POST-OOPS system should run packages built at any time. ... It's pretty damn confusing, I agree. :) But, the upshot is there's two ways to fix these ports issues: 1) recompile all of the ports. It doesn't matter what version you're on, recompiling will fix the port. (Reinstalling from a binary package may not.) 2) update your system to the latest 6-POST-OOPS. Again, should fix everything. (I haven't tested this myself, but reports are that it works.)

Update 3

And, if you're having build issues this should help (from '/usr/src/UPDATING'):

20071024:
A breakage was introduced in libc and fixed later. Make sure you have lib/Makefile rev 1.205.2.4. If it already breaks your world, you can recover it by

- reboot to single user mode, make sure you use /rescue/sh instead of /bin/sh
- use /rescue/chflags to remove schg flag on /lib/libc.so.6
- use /rescue/cp to copy libc.so.6 from /usr/obj to /lib/libc.so.6
- continue installworld, you should be fine now

Color your (CLI) world!

Here is a quick tip on adding some color to your command line interface (CLI). And, when I say CLI, I mean both the console and your typical graphical terminal as well (xterm, Eterm, etc.).

First, and easiest, is to color the directory listings. There are two ways to do this. One, you can define the variable CLICOLOR in your environment. In bash, you could do this with the command "export CLICOLOR=1". And, if you really like it, then just put that same statement into your ".bash_profile" file and it will become effective every time you log in. See picture above, and then say either "oooh!" or "aaah!"

The other way to do the exact same thing, is to just add the option "G" to your "ls" commands. Above, I could have gotten the exact same output by typing "ls -ltG" regardless of whether the variable CLICOLOR existed in the environment. I guess if you're already using an alias for "ls" this might be a good way to do it. If you're using several aliases for several different sort of "ls" commands, then maybe CLICOLOR would be better. But, they're both easy to set-up and it doesn't much matter which method you use.

Next, let's get some syntax-sensitive color into our text editor. If you use "vi"* and you do any sort of scripting or programming, you should try installing the port "editors/vim". In fact, I install "editors/vim-lite" because I'm really not interested is using the graphical/X vim. Now, if you open any sort of script file that vim can tell is a script or program**, all you've got to do is enable the syntax setting by typing ":syntax enable" (make this automatic by putting it into your "~/.vimrc" file, colon and all). Once this setting is enabled, vim will color the different words and comments on the screen according to the syntax of the appropriate language -- as long as it has rules settings for that language -- and it has rules already for most. I can tell you it works nicely out of the box for shell and python scripts. If you don't have any scripts or code files handy, see the magic at work on one of the scripts that's already on a FreeBSD box. Maybe try, "vim -R /etc/rc.sendmail". See the screen snip below. Say "aaah!" or "oooh!" as appropriate.


Being an old crank, I've been known to poo-poo this fancy color stuff. By golly, when I was your age we had amber-only WYSE terminals that burned off your eyelashes and warmed all coffee within a 5 foot radius! But, I've got to admit, once you've had a taste of this syntax-sensitive, visual sugar, there's no going back. It really helps you to take in your scripts a lot quicker. And, once you're used to it, you'll howl the next time you have to script or program without it.

*(If you don't use "vi", then I recommend it as a great CLI tool -- and, obviously, its clone "vim", too. Be aware that they're not really, really easy to learn. :) But, they're worth the trouble and can help you to navigate and change files much more quickly than any standard editor.)
**(The way vim normally tells which syntax to use is via the interpreter defined after the shebang on the first line of the script. It might also use file extensions when there is no interpreter defined.)
***(Cool wallpaper behind my transparent Eterm is from Digital Blasphemy.)