[gentoo-amd64] Re: Some weird issues with portage

[Duncan]

"Tonko Mulder" <tonko.mulder@×××××.com> posted
43ba12950811200057t7d6ad5fehbe03184c6f56b006@××××××××××.com, 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