The summary says everything... I've discovered this because I was trying to configure a kernel in XTerm with "make menuconfig" and all what I've seen was a black screen! Not very funny... Swithcing back to the console I've seen messages like "XTerm: cannot allocate color XXXXX..."! Workaround: cp /usr/share/emacs/21.4/etc/rgb.txt /usr/lib/X11/rgb.txt Reproducible: Always Steps to Reproduce: Gentoo Base System version 1.4.16 Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r7 x86_64) ================================================================= System uname: 2.6.10-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 13 2005, 15:49:06)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.inode.at" LANG="en_US" LC_ALL="en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 16bit X a52 aac acpi acpi4linux alsa asm audiofile avi bash-completion bitmap-fonts blender-game bzip2 ccache cdda cdparanoia cdr codecs cscope css cups dpms dv dvd dvdr dvdread emacs emul-linux encode esd fam fame ffmpeg flac font-server freetype ftp gif gimp gimpprint glut gnome gphoto2 gpm gstreamer gtk gtk2 imlib java jp2 jpeg kde lm_sensors lzw lzw-tiff motif mp3 mpeg mpeg4 mplayer multilib ncurses nls nptl opengl pam pdflib perl png python qt readline rtc sdl ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts unicode usb userlocales utf8 xml2 xmms xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, PORTDIR_OVERLAY
donnie@supernova ~ $ equery files xorg-x11 | grep rgb.txt /usr/lib/X11/rgb.txt donnie@supernova ~ $ equery list xorg-x11 [ Searching for package 'xorg-x11' in all categories among: ] * installed packages [I--] [ ] x11-base/xorg-x11-6.8.2 (0) Please provide the output of the above commands and reopen. equery is part of gentoolkit.
bash-2.05b# equery files xorg-x11 | grep rgb.txt /usr/lib64/X11/rgb.txt bash-2.05b# equery list xorg-x11 [ Searching for package 'xorg-x11' in all categories among: ] * installed packages [I--] [M ] x11-base/xorg-x11-6.8.2 (0)
Should I change: RgbPath "/usr/lib/X11/rgb" to RgbPath "/usr/lib64/X11/rgb" ? Isn't /usr/lib/X11/rgb the "right" place?
ls -ld /usr/lib* Jeremy, you can speak more as to what the "right place" should be on amd64.
bash-2.05b$ ls -ld /usr/lib* drwxr-xr-x 54 root root 28672 Feb 19 16:07 /usr/lib drwxr-xr-x 3 root root 4096 Feb 18 18:26 /usr/lib32 lrwxrwxrwx 1 root root 8 Feb 18 15:41 /usr/lib64 -> ../lib64 drwxr-xr-x 5 root root 4096 Feb 17 09:45 /usr/libexec
lrwxrwxrwx 1 root root 8 Feb 18 15:41 /usr/lib64 -> ../lib64 That's wrong. Delete it and run `ln -s /usr/lib64 lib` This should already be fixed in the current ebuild.
I've done this: cd /usr rm lib64 mv lib lib64 ln -s /lib/lib64 lib bash-2.05b# ls -ld /usr/lib* lrwxr-xr-x 1 root root 11 Feb 20 09:45 /usr/lib -> /usr/lib64/ drwxr-xr-x 3 root root 4096 Feb 18 18:26 /usr/lib32 drwxr-xr-x 54 root root 28672 Feb 19 16:07 /usr/lib64 drwxr-xr-x 5 root root 4096 Feb 17 09:45 /usr/libexec But now everything is confused... because packages that have installed files under "/usr/lib64 --> /lib64" now cannot find them, because "/usr/lib64" is now different than "/lib64"! So there are files under "/lib64" that should go under "/usr/lib64"... how can I fix this? Reemergin broken packages will do the trick but it will leave files under "/lib64"...
That's unfortunate -- you can 1. try unmerging non-vital packages that do so, then switch the symlink, then reinstall them ... or 2. just switch the symlink and delete duplicates from lib64, or 3. switch the symlink and copy them over manually.
Another IDEA: I think that something like: qpkg -l | grep '^/usr/lib64/' | cut -d'/' -f4 | cut -d' ' -f1 | sort | uniq will give me a list of thing that I should move... looks sane?
Yeah, looks good -- assuming there's nothing that's _supposed_ to be in both /lib64 and /usr/lib64, which would be a pretty weird case.
Ok.. the correct command should be this (with -nc option): qpkg -nc -l | grep '^/usr/lib64/' | cut -d'/' -f4 | cut -d' ' -f1 | sort | uniq since without "-nc" "grep '^/usr/lib64/'" will discard colored lines ;-) Now the system works almost fine... almost because I've some messages like "Warning: locale not supported by Xlib" or "Failed to open input method"... I'll try to figure out what's wrong with libs...
