22 November 2007

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'):
A breakage was introduced in libc and fixed later. Make sure you have lib/Makefile rev 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



At 22/11/07 15:09, Anonymous Anonymous said...

i've got same problem but i don't understand how to fix it can you tell me how to fix
/libexec/ld-elf.so.1: bash: Undefined symbol "__sbmaskrune"

At 22/11/07 18:46, Blogger kace said...

First, delete the messed up bash port: maybe with "pkg_delete bash-3.2.5" (or maybe different version number for you), or with "cd /usr/ports/shell/bash ; make deinstall ". Then, install the port again with "cd /usr/ports/shell/bash ; make install" (not with "pkg_add"!).
That's what fixed it for me while running FreeBSD 6.2-R. If you're on a different version, you might have something else going on.

At 7/12/07 18:05, Blogger David said...

I've had this problem has well, my bash package could be installed on a FreeBSD 6.3-PRERELEASE, but not on FreeBSD-6.2-RELEASE.

It was because of lib : /lib/libc.so.6 (different on both machine).

I've done a make world and make installworld on 6.2 machine and it solved the problem.

Of course, you could just compil bash on your system, it will use the right libc and will solved the problem as well.

At 10/12/07 04:53, Anonymous Anonymous said...

the _problem_ is when the port is _only_ in binary form. I liked to used xnview, but for now, I can _not_ used it, and no, I can _not_ compile it becouse it has no sources :-(
It's a pitty... perhaps some adds to /etc/libmap would workaround this problem, but I don't know how to do it.

Thank you very much.

At 10/12/07 23:52, Blogger kace said...

@David: So, you upgraded your 6.2 machine to 6.3 if I'm understanding you. Yes, that would be another way to fix this -- maybe even a shorter way if you've got a lot of ports messed up! (I didn't want to do that yet on the particular machine it happened on.)

@curioso: There's always options. Like above, if you're able/willing to upgrade the OS to 6.3 it should accommodate the package. An easier way would be to find a package for it that is pre-6.3. The 6.2 release package ought to do the trick.

At 13/12/07 07:17, Anonymous Anonymous said...


Thank you very much for thi answer. But, look at this:

$ uname -a
FreeBSD pcbsd 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Wed Dec 12 12:53:10 CET 2007 root@pcbsd:/usr/obj/usr/src/sys/PCBSD-SMP i386

yes, I have upgraded my pcbsd 1.4 to 6.3 prerelease without any problem and all works fine. Now, see this:

$ pkg_info | grep xnview
xnview-1.70 An easy graphics viewer / converter

yes, I have xnview 1.70 version, the one of the 6.2 release (I have all ports up to date).

But, If I run xnview, I see:

/libexec/ld-elf.so.1: /usr/local/lib/libX11.so.6: Undefined symbol "__sbmaskrune"

The only "workaround" that I can find is to install wine (the windows compatibility layer) and run the xnview windows versions of my Windows XP disc partition. And I have discovered that it runs very fast and it has many options than unix version. I really need the amazing xnview's batch file conversions utils

Thank you again for your answer and your interest

At 15/12/07 17:33, Blogger kace said...

@curioso: I've tried to clarify the issue with another update. But, I'm afraid that you might have applied two solutions that, together, only reversed the problem.

Anyway, I'm not sure how system upgrades work in PCBSD, but it appears that you're not upgraded to the latest system sources. When I upgraded a box last week (cvs tag=RELENG_6_3), I got 6.3-RC1 in my 'uname'. ... You might keep looking for a package that will work with it, maybe this or this. Good luck.

At 16/12/07 01:08, Anonymous Anonymous said...

I have the same problem.. bash is my default shell, so I can't login via ssh and I don't have console access to the machine. Any suggestions? Thanks

At 16/12/07 10:36, Anonymous Anonymous said...


Thank you again.

I have read your new update, but I don't want update _all_ my ports (I have 624 and I'm afraid it tooks serveral days).

I don't know how system upgrades works in PCBSD, but I think is quite similar to "real" FreeBSD... but I don't know why my uname say "PRERELEASE" instead of "6.3-RC1". I have upgrade to cvs tag=RELENG_6 some minutes ago and my system insist: uname "PRERELEASE".

Besides, I have tryed the links you kindly give me, but the /libexec/ld-elf.so.1: bash: Undefined symbol "__sbmaskrune" error doesn't go away.

As usual, thank you very much for your interest :-) for now, I'm happy with emulated XnView until a new version (or perhaps a source version) is available.

Best regards from Sevilla -Spain-

At 16/12/07 23:15, Blogger kace said...

Gerard: This is a tough nut to crack, but I think I've got something. Try these exact commands (less #comments) (there won't be any prompt, don't sweat that):

ssh your-box "/bin/sh "
export EDITOR=ex
#should echo the shell line here
#enter pw at prompt (it will echo)

Now you can log in as yourself and then su to root. 'su' isn't possible directly from the ssh->sh because of security restrictions on ssh. Good luck!

At 18/12/07 00:30, Anonymous Anonymous said...

kace, Thanks for your help. Unfortunately it would try to execute bash before any of the commands so I ended up having to pay the hosting company to boot into single user and fix it for me.
Thanks again.

At 18/12/07 09:48, Blogger kace said...

Gerard, You're quite right. I tested the above, but forgot to break my bash executable first. Of course, the '/bin/sh' is being passed to bash. Thank you for replying.

This is an unhappy reminder that all of us bash users should have a back-up user account to guard against this sort of problem.


Post a Comment

<< Home