When I try to compile gvfs I get the following error: x86_64-pc-linux-gnu-gcc: /usr/lib64/liblzmadec.so: No such file or directory make[4]: *** [gvfsd-archive] Error 1 Use flags: archive -avahi bash-completion bluetooth* cdda -doc -fuse -gdu+ gnome -gnome-keyring -gphoto2 hal -samba udev+ build_options: -optional_tests split strip -trace -preserve_work Reproducible: Always
please attach a full build.log and emerge --info.
Created attachment 217408 [details] Output of gvfs compilation
Created attachment 217409 [details] Output of paludis -I gvfs
Can somebody extract some sense out of paludis again, I still can't read the hideous blob.
also, did you run revdep-rebuild/reconcilio ? It sounds like your system is getting the lzma dependencies out of its ass (if you excuse me the expression) so a consistency check would be in order.
(In reply to comment #4) > Can somebody extract some sense out of paludis again, I still can't read the > hideous blob. I'm really sorry for that. When I chose the package manager I didn't intend to bother other people.
(In reply to comment #5) > also, did you run revdep-rebuild/reconcilio ? It sounds like your system is > getting the lzma dependencies out of its ass (if you excuse me the expression) > so a consistency check would be in order. I've run reconcilio and I see the following output: Broken packages: * gnome-base/gvfs-1.2.3::installed /usr/libexec/gvfsd-archive (requires liblzmadec.so.0) However, this tries to compile gvfs, which gives the same error. I forgot to mention that I've recently added the bluetooth use flag to my system, and I've recompiled all the packages accordingly. The only package giving me problems is gvfs.
(In reply to comment #7) > (In reply to comment #5) > > also, did you run revdep-rebuild/reconcilio ? It sounds like your system is > > getting the lzma dependencies out of its ass (if you excuse me the expression) > > so a consistency check would be in order. > I've run reconcilio and I see the following output: > Broken packages: > > * gnome-base/gvfs-1.2.3::installed > /usr/libexec/gvfsd-archive (requires liblzmadec.so.0) > > However, this tries to compile gvfs, which gives the same error. > > I forgot to mention that I've recently added the bluetooth use flag to my > system, and I've recompiled all the packages accordingly. The only package > giving me problems is gvfs. I reopened the but because I still have the same problem, and I've provided all the information requested.
I can confirm this bug. Some time back there was an issue about the lzma packages merging to one or something. I remember that as a result there was a few libraries renamed and this was fixed for all packages that had the lzma flag or that depended on lzma packages. liblzmadec.so was on of the libraries that was renamed: https://bugs.gentoo.org/show_bug.cgi?id=284458 For some reason gnome-base/gvfs does not have this flag nor does it depend on any lzma package. So, I think gnome-base/gvfs has just been forgotten in the process. For me this bug occurred just after this update process because I happened to add cdda flag which triggered the gnome-base/gvfs to be reinstalled. I tried also installing 1.4.3 or 1.4.2 (can't remember just now) with no help. Because at the time I tough that this will be fixed very soon and gnome was not a vital part of my system I did not care to report it. Because I'm also using paludis I can't confirm if this is just a paludis issue or not but I highly doubt it.
Gvfs 1.4.3 still fails to compile.
could you grep for lzmadec in /usr/lib64/*.la and through /usr/share/pkgconfig and /usr/lib64/pkgconfig ?
The output of 'ls /usr/lib64/*.la | grep lzmadec' is: /usr/lib64/liblzmadec.la 'grep -r lzmadec /usr/share/pkgconfig/' and 'grep -R lzmadec /usr/lib64/pkgconfig/' returns no matches.
A similar problem was reported upstream for XBPS: https://bugs.launchpad.net/xbps/+bug/453422 Their solution was to change lzmadec to lzma, FWIW. (I'm also on paludis and with bluetooth USE flag.)
What should be the best way to fix this? Patch the ebuild?
did you guys try rebuilding libarchive ?
Yes, I still get the same error.
(In reply to comment #12) > The output of 'ls /usr/lib64/*.la | grep lzmadec' is: > /usr/lib64/liblzmadec.la I think "grep lzmadec /usr/lib64/*.la" is what was intended. If it is libarchive that's trying to pull in lzmadec, even after rebuilding it, a build log and config.log of libarchive might help.
Sorry for that. The output of `grep lzmadec /usr/lib64/*.la` is: /usr/lib64/libarchive.la:dependency_libs=' -L/usr/lib64 -lacl -lattr -lcrypto -llzmadec -lbz2 -lz' /usr/lib64/liblzmadec.la:# liblzmadec.la - a libtool library file /usr/lib64/liblzmadec.la:dlname='liblzmadec.so.0' /usr/lib64/liblzmadec.la:library_names='liblzmadec.so.0.0.0 liblzmadec.so.0 liblzmadec.so' /usr/lib64/liblzmadec.la:old_library='liblzmadec.a' /usr/lib64/liblzmadec.la:# Version information for liblzmadec.
What package is owning /usr/lib64/liblzmadec.la ? # equery b /usr/lib64/liblzmadec.la should point to it
Seems that they have tried to resolve this bug in the mailing lists: http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg99346.html
(In reply to comment #20) > Seems that they have tried to resolve this bug in the mailing lists: > > http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg99346.html > In summary, seems that the problem was caused by orphan .la files still present in your system. But, why are they present on your system? I think that this should be closed as WORKSFORME then
Now that I actually read the hole thing and found out that in my system there was also an orphan file in /usr/lib64/libarchive.la. After removing it gvfs compiled just fine. I just have no idea why it was still there. So seems that this is more or less solved.
Aye. Removing that stray libarchive.la made gvfs compile for me too.
Closing then. Thanks a lot for the follow up.
