Andreas Calvo posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 12 Mar 2005 10:53:40 +0000:
> Well, I was following the steps to a 2005.0 multilib profile, when in > the last step I've had to do an emerge -uv world. At this time I start > watching how almost all the packages were breacking because they > couldn't find some requirements in /usr/lib... So I've started to > symlink every one of them, and that was fine with emerging. But now, > after all the emerge -uv world, a lot of things do not work... Gdm was > not working because I've had to symlink the /usr/lib64/pango to > /usr/lib... > What's wrong with that? Why are all the libraries mess up? I've seen the > script from eradicator but it almost killed all the system, I've had to > reboot with a livecd and move the backup .tar.gz to its default > location... Well, I hope anyone know what's happening, and can give me a > hand Eventually, with 2005.1 or perhaps later, the goal is to have 64-bit libs in lib64, with 32-bit libs in the old lib. That's what the LSB is calling for and what pretty much every other distribution with an amd64 port is doing. However, there are a quite a few ebuilds that aren't ready for that yet in Gentoo. They install their 64-bit libs to lib instead of honoring the system multi-lib settings and putting them in lib64 when that is set. Therefore, we can't make lib the 32-bit home just yet. With 2005.0, lib32 remains the 32-bit home, and lib64 the 64-bit home, with the "bad" ebuilds still placing their 64-bit libs in lib instead of lib64. Complicating matters for those upgrading are all the old libraries installed to lib that would be installed to lib64 now, and all the applications that still look to lib instead of lib64 to load their libraries. (This is a bit of a simplification, but...) Thus, currently, either lib needs to be a symlink to the parallel lib64, or lib64 needs to be a symlink to the parallel lib. Which you have will depend on your installation, but making lib64 the "real" location and lib the symlink, with slightly simplify things for the next upgrade. >From your post, it appears you have both the lib location and the lib64 location (for at least /usr/lib(64)) as real dirs. That WILL cause problems, as you are finding out. You need to move all the libraries from one location to the other and then erase the empty dir and make it a symlink to the other location. Unfortunately, it's not necessarily quite that easy, as you may have two different versions of the same file in the two different locations, and you'll need to figure out which one is newer and keep it. You'll also need to ensure that all the lib*.so(.*) symlinks point to their correct real counterparts. It's also possible that you were hit with the xorg bug. One version of xorg scrambled up the symlinks, and pointed one of the /usr/lib locations to /lib (not usr), a symlink that should NOT be pointed like that in ANY case. There are a number of folks with semi-broken systems due to this error, unfortunately. The devs are creating a script to help sort it out, but I don't know the status on that. (I luckily seem to have missed this problem, so haven't been following it as closely as I would have been if I had it.) In either case, after you straighten out the dirs, you'll probably have to run the fix_libtool_files.sh script (run it without any command line options to get a short help message) to straighten out some stuff, and may have to correct other library references in the *.la files manually, unless you decide to wait for the fixer script the devs are making, and hope that catches most if not all of it. One other helpful hint... If you've had FEATURES=buildpkg on, packages will have been backed up to a binary package as they were emerged, so once you get the file system straightened out, you should be able to emerge -K those packages, and get everything back in order without having to emerge from source. I've been doing this for awhile, and it has already come in handy several times. Of course, if the binary package was created with the lib location, it'll still be used instead of lib64, but if lib is a symlink to lib64, it should work anyway. The problem you are having right now is that they aren't symlinked, but pointing to two different locations. That's what's happening. Unfortunately, you are likely to have some sorting out to do, particularly since you've been creating other symlinks in the mean time and may have further screwed things up. It should be possible to straighten things out, but it'll probably take some serious time and patience. Under the circumstances, some may choose to scrap their current installation and start over, altho I'm the type that normally prefers to try to work thru it and learn a bit more about my system as I go, rather than starting over. I wish you /lots/ of patience, as unscrewing this one will probably take it, unfortunately. =8^\ -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
