Instead of installing all files/directories to /usr/X11R6/lib64 and creating /usr/X11R6/lib as a symlink, /usr/X11R6/lib is created as a directory, and most files/dir's are installed there. Only X11/~doc, X11/fonts modules and all .so-files are going to lib64. /usr/X11R6/lib64 istn't listed in /etc/ld.so.conf, so X11 and every app depending on xlibs fail to start. Reproducible: Always Steps to Reproduce: 1.unemerge xorg-x11 2.remove /usr/X11R6 3.emerge xorg-x11 Actual Results: result as discribed above, lib and lib64 are both directories in /usr/X11R6 Expected Results: /usr/X11R6/lib have to be a symlink to /usr/X11R6/lib64
Does it work if you export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/X11R6/lib64"?
With export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/X11R6/lib64" applications linked against xlibs work again (tested with mc and mplayer), but startx still results in: X: error while loading shared libraries: libXau.so.6: cannot open shared object file: No such file or directory xinit: Server error. Without LD_LIBRARY_PATH set I got: xauth: error while loading shared libraries: libXau.so.6: cannot open shared object file: No such file or directory six times.
Run `qpkg -l xorg-x11 | grep libXau.so` please. If you don't have qpkg, emerge gentoolkit.
jo@theben:~$ qpkg -l xorg-x11 | grep libXau.so /usr/X11R6/lib64/libXau.so.6.0 /usr/X11R6/lib64/libXau.so.6 -> libXau.so.6.0 1096284827 /usr/X11R6/lib64/libXau.so -> libXau.so.6.0 1096284827
Some AMD64 people, could you tell me whether both lib and lib64 should be in LDPATH or just one of them? Thanks.
eventually lib should hold 32bit libs, but that's a long ways off. i hadnt really thought much about it... but yeah. the 64bit xorg-x11 should be using lib64 and not lib, since eventually lib should hold 32bit libs. however, the symlink needs to stay in place since not everything will install to lib64. in fact, nothing will unless you use the lib64 profile, and i do NOT suggest using the lib64 profile yet, as half the damn tree will break with it! so yeah, the lib symlink should eventually be removed, but we just cant do that yet.
Fixed in files tarball 0.4, applied to >=6.8.0-r1.
