On 3/12/10, Damian <damian.o...@gmail.com> wrote: > On Fri, Mar 12, 2010 at 9:05 AM, Damian <damian.o...@gmail.com> wrote: >>> Anyway, if it were me I'd nuke the file in a heartbeat, but if OP is >>> too timid for that, he can also quarantine the file first, i.e., move >>> it to some other path where it won't cause trouble (and then delete >>> later). Also, (from the bug) his libarchive.la seems to still list the >>> .la, so he should re-emerge libarchive after moving away the orphaned >>> .la-file (or use lafilefixer?). >> Ok, the OP will try this. If I cannot fix it I will just install gvfs >> without the archive flag. > Ok, so moving the file, reinstalling libarchive, and running > lafilefixer didn't change the situation. > > So I'm using gvfs without the archive flag.
Bummer. Are you sure your libarchive.la is not another orphan, just like liblzmadec.la was? Please check (if you are still interested in hunting down the cause). You should probably only end up with that la file if you have USE="static-libs" for libarchive -- which (if I'm reading correctly the paludis output attached in the bug) you do not have currently enabled. But since you have the libarchive.la file on your system you may have had the USE flag enabled at one point, or the ebuild may have changed to allow separate dynamic and static building while your package manager might not have kept up with its records. So, also check the owner of libarchive.la, and clean up if necessary. Actually, since you seem to run a great risk of having more than one orphan .la-file then maybe you should do something like "find /usr -name '*.la' | xargs -r equery belongs" or some such generic flush-out of orphaned .la files. -- Arttu V.
