"Tonko Mulder" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Nov 2008 08:57:17 +0000:
>> This looks very strange to me. Empty shared-object libs? >> >> FWIW, I have gmime-2.2.23 (only, no 2.4.x) merged here, with USE=-mono, >> and equery b libemeraldengine.so returns nothing, so those >> libemeraldengine.so* files must be mono related. >> > It's not just pan/gmime, it's for every ebuild. I now also get 'compiler > cannot create executable' and I forgot what the solution for that was. Now /that/ might explain the empty *.so* libs as well. If it can't create executables, it likely can't properly create libraries either. That might have been when it started, right there. If you're getting compiler can't create executables on top of the other thing, it could mean whatever was the problem has caused other problems and your systems getting more and more screwed up. Tread carefully, or you may end up having to reinstall from a stage tarball and effectively start over (but without having to repartition and all that, starting from the stage tarball). If you've been using FEATURES=buildpkg, you probably have a working gcc package you and remerge over top of the old one, to fix gcc if it becomes necessary. If not, you can unpack a stage tarball into a testing area, chroot into it, quickpkg up the gcc version that's there thus creating a binary package, then back outside the chroot again, emerge -K the binary package you created. That's the usual emergency procedure to restore a working gcc. Of course, that gcc will be the one from the stage tarball, and you'll have to use it to remerge a normal system gcc with your own USE flags, etc. If portage or python (which portage needs to work) is screwed, the emergency procedure for replacing it starts the same way (unpack a stage tarball, chroot into it, use quickpkg to create a binpkg of whatever you need), but once out of the chroot, you have to do something different as the portage you'd merge the binpkg with is broken. In that case, first backup config files such as make.conf that the package will include and thus will overwrite if you use this procedure, then untar the binary package (which is a tar.bz2 with some extra data glued on the end) to /, directly over top of your working system. That should get you a working portage or python or whatever again, but as I said, any config files that the package would have normally updated will be directly overwritten with the default versions. Thus the backups, which you can now restore over the default versions. Of course, if the brokenness was in your config files, that will break it again, but you'll already have the package available to untar over / again, and you'll /know/ it's in the config the second time around and can be more careful restoring your backup config. At this point you should be working again, but since you bypassed portage, its idea of what's installed will be out of sync with what's really installed. Thus, you'll need to remerge a working package once again to get portage back in sync, and you may have a few stale files to cleanup by hand as well, if the filenames changed or the packages otherwise didn't install exactly the same files. Still, that's better than having to start from the stage tarball and reinstall /everything/. > I don't see that path in my emerge --info, but FYI the full path is > ~/dev/repo/portage and it's my git based portage tree (testing) by > Daniel Robbins. "Oh, well, carry on then." =;^) FWIW I saw it in your login prompt, but missed the ~ at the beginning, which makes /all/ the difference. Now that you've explained it, pointing out my /small/ oversight which wasn't so small after all =:^(, it makes perfect sense. So, um... yeah... carry on! Don't mind me! Nothing to see here! =;^) -- 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
