Command line not responding

[Michael Gass]

On Fri, May 17, 2013 at 11:55:13AM -0700, Jeremy Chadwick wrote:
> On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote:
> > Running 9.0-Stable on an i386.
> > 
> > Whenever I type a command at the prompt I get
> > the output
> > 
> > /usr/local/lib/libintl.so.9: Undefined symbol "_ThreadRuneLocale"
> > 
> > and nothing else - the command will not run. Just the
> > above output.  Commands like "ls" and "exit" work, but not much
> > else.  This happends whether I am logged in a user or as root.
> > Cannot even halt the system from the command line.
> > 
> > Started to happen after trying to update the freetype2 port.
> > Got an error msg while updating libXft-2.1.14.  From that point
> > on I cannot use  the command line.
> > 
> > I have no idea what to try.  Any suggestions.
> 


> First provide the contents of /etc/make.conf and /etc/src.conf.
> 

Thanks for getting back to me. Here are the contents of the two
files.  I rebuilt the kernel last fall and have updated ports
fairly regularly since. Things have worked fine until today when
I tried to update ports.

# File:		make.conf
# The ? in the below is for buildworld
CPUTYPE?=pentium2
# Uncomment the below for general builds.
CFLAGS= -O -pipe
# Uncomment the below for kernel builds.
# COPTFLAGS= -O -pipe
NO_PROFILE=true
INSTALL_NODEBUG=true
#WITHOUT_DILLO_IPV6=yes
#WITH_DILLO_DLGUI=yes
# added by use.perl 2013-05-17 11:04:30
PERL_VERSION=5.12.4

# File: 	src.conf
WITHOUT_PROFILE=true
WITHOUT_BLUETOOTH=true

> The _ThreadRuneLocale thing has come up before, but on -CURRENT circa
> early 2012.  It happened to a user when trying to build kernel (really)
> and that user was tinkering about in make.conf and src.conf heavily,
> messing with Clang.  I personally remove Clang from my systems entirely
> for many reasons, by simply doing WITHOUT_CLANG=true in src.conf and
> thus rely entirely on gcc.
> 
> My recommendation, and this isn't going to make you happy:
> 

I may do this if I cannot get things to work otherwise. I appreciate the
advice.

> Boot into single-user, mount your filesystems, and try commands there,
> in hopes that they work.  If they do:
> 
> pkg_delete -a -f
> cp -pR /usr/local /usr/local.old
> rm -fr /usr/local/*
> reboot
> 
> Boot into multi-user, log in, and things should be fine.  Next:
> 
> rm -fr /var/db/ports/*
> rm -fr /usr/ports/distfiles/*
> find /usr/ports -type d -name "work" -exec rm -fr {} \;
> 
> Now begin rebuilding your ports.  If you prefer to use packages, go
> right ahead, given that this was just announced a few days ago:
> 
> http://lists.freebsd.org/pipermail/freebsd-announce/2013-May/001476.html
> 
> But I tend to build everything from source, barring large-ish packages
> (things like cmake, python27, perl) which I pkg_add -r.
> 
> My attitude has always been when something catastrophic impacts a very
> large number of commands (particularly a library with a missing symbol
> that a very large number of programs link to), start fresh.  It's
> not worth scrambling around with leftover cruft in place that could
> appear months later and make you say "I thought I fixed that!", where
> you then have to follow up to a thread months old and admit "actually
> there is more breakage..."
> 
> Footnote: I am likely to get a large amount of backlash for proposing
> the above, with claims that will equate it to fixing a minor cut by
> amputating the entire limb.  My response to such: that's nice.
> 
> -- 
> | Jeremy Chadwick                                   jdc at koitsu.org |
> | UNIX Systems Administrator                http://jdc.koitsu.org/ |
> | Mountain View, CA, US                                            |
> | Making life hard for others since 1977.             PGP 4BD6C0CB |

-- 
Michael Gass				
mgass at csbsju.edu