I get a Segmentation Fault when I search for anything in nano. It seems the culprit is nano-1.3.10-crash patch: I tried recompiling nano without it and the problem disappeared. Under gdb I get: 0xb7ef74ee in __malloc_consolidate () from /lib/libc.so.0 I couldn't get a full backtrace since I don't know how to get debug symbols into the executable. I tried adding "-g" to both CFLAGS and LDFLAGS but it didn't work. emerge --info follows: Portage 2.0.54-r2 (!/usr/local/portage/profiles/uclibc/x86/2.6, gcc-3.3.5-20050130, uclibc-0.9.28-r0,uclibc-0.9.27-r0, 2.6.16-suspend2-r4 i686) ================================================================= System uname: 2.6.16-suspend2-r4 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.4-r1, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-Os -march=athlon-xp -mmmx -msse -m3dnow -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=athlon-xp -mmmx -msse -m3dnow -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks sandbox userpriv usersandbox" GENTOO_MIRRORS="http://85.25.128.62 http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://213.186.33.38/gentoo-distfiles/ http://213.186.33.37/gentoo-distfiles/ http://gentoo.inode.at/" LANG="en_US.UTF-8" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext aac alsa apache2 arts bitmap-fonts bzip2 canvas crypt css cups dar64 dga doc dvd encode examples ffmpeg firefox flac fuse gif glibc-omitfp gphoto2 gpm gstreamer gtk gtk2 image imlib immqt-bc java jpeg jpeg2k kde kdeenablefinal kdexdeltas mad matroska mmx mmxext mozdevelop mozsvg mp3 musicbrainz ncurses nptl nptlonly offensive ogg oggvorbis on-the-fly-crypt opengl pam physfs pic png qt quicktime rdesktop readline real rtc ruby sdl sndfile speex sse ssl subversion svg theora threads tiff truetype truetype-fonts type1-fonts usb userlocales vorbis win32codecs wmf xanim xml2 xmms xv xvid xvmc zlib" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Somehow you have two libc's installed. Thats for sure incorrect.
I upgraded my uClibc and portage didn't unmerge the old version. I tried to do that manually but it destroyed my system :( Anyway, my system was functioning properly before that. I compiled vanilla nano and it ran flawlessly.
nano really works fine when using the current uclibc-0.9.28 I think the result of the nano crashing for you is based on your messed up system.
I tried again and I encountered the same problem. Unfortunately it seems I cannot upgrade uClibc to 0.9.28 without leaving two versions installed. It probabily has to do with the fact that I'm using an old uClibc stage3 (based on 2005.0). I couldn't find anything else to get a full uClibc-based gentoo; I'd appreciate if you could give me some pointers. I mark this bug as invalid since it probably affects only me and it cannot be confirmed. Thanks for your help anyway. ;)
Oddly enough I noticed when going from 2005.1 stage1-ppc-uclibc with a current tree that every pkg wants to slot itself. Including libc/portage/bash etc. Is that more or less how you got into the mess of two libc's installed?
No, I DID manage to upgrade other packages. Not so for uClibc. I think the problem lies in uClibc's infamous binary incompatibility. An upgrade should force a world rebuild. Also, portage, python, gcc etc. should be compiled statically. Mhmmm... Btw, you have a 2005.1 uclibc stage? Where did you get it? I could only find 2005.0 stages (under experimental/embedded).
Sorry I ment. 2005.0 I've been maintaining several binary repos for several uclibc arches. http://tinderbox.x86.dev.gentoo.org/html/uclibc/ What I do is point my portage at it and run from there. PORTAGE_BINHOST=http://tinderbox.x86.dev.gentoo.org/uclibc/i386 It greatly speeds up install/upgrade times for me. Current uclibc stages are delayed due to a coreutils/sandbox bug. Oh and I figured out why we are seeing every pkg get sloted on fresh installs. http://planet.gentoo.org/developers/solar/2006/05/16/before_i_go_to_sleep
