I have updated a machine from half-year old stable Gentoo Linux using emerge -n gnome. It has failed: 1) /usr/lib/*.la contains /var/tmp/portage/* references, it breaks further compilation After manual fixing it, I was able to merge GNOME, but I went into problems again: 2) GNOME-VFS is broken and searches for icons and menu in /var/tmp/portage/*: (nautilus:2067): GdkPixbuf-CRITICAL **: file gdk-pixbuf-io.c: line 729 (gdk_pixbuf_new_from_file): assertion `filename != NULL' failed /bin/cp: cannot stat `/var/tmp/portage/nautilus-2.4.1-r2/image//usr/share/nautilus/starthere-link.desktop': no such file or directory ** (nautilus:2067): WARNING **: Failed to execute command '/bin/cp /var/tmp/portage/nautilus-2.4.1-r2/image//usr/share/nautilus/starthere-link.desktop /home/sb/Desktop/starthere.desktop' ... Cannot open desktop file applications:///nautilus.desktop... Trying strace gnomevfs-ls, this file is searched in /var/tmp/portage. I have tried to upgrade libtool and recompile glib and gnome-vfs. No change. I have tried to upgrage libtool to latest UNSTABLE version. It fixes the problem! Fix: There is no bug in GNOME ebuilds. Upgrading libtool to latest unstable one fixes all problems. Either make latest libtool stable, too, or fix portage to use DESTDIR. Maybe only gnome2.eclass should force DESTDIR use (AFAIK GNOME should be completely DESTDIR-clean). Reproducible: Always Steps to Reproduce:
Uhm you are apperantly the only one seeing these problems, so i'd say it's probably something on your side. As you say it's probably your libtool. Well i'm not using latest unstable, nor are most of our users, so that would give a lot fo trouble if what you say is true for everyone ? I'm not sure what you want me to do with this bug. If you can reproduce a problem with /var references in specific *.la files (of gnome packages) we can look at that, but without that this bug is pretty useless to me. And i'd say you are good enough a dev to know that.
what versions of libtool are you using? which version have problems? i haven't seen anything like this so far, stable or unstable. i use /fire/1/portage/scratch as my /var/tmp: mcvaio ~ % fgrep fire /usr/lib/*.la mcvaio ~ % unless makefiles modify/recompile (not relinking) during "make install", i don't see why this is a problem whether we use DESTDIR or prefix. and some build processes do that, that is why there is a provision in the gnome2.eclass to use DESTDIR instead.
Maybe I was only one, who tried to upgrade any machine after half year by command "emerge -n gnome" without any "emerge world", hoping to have machine working GNOME 2.4. There is the log of my activities: I have had installed long time ago: gcc-3.2.2 glibc-2.3.1-r4 autoconf-2.57-r1 portage-2.0.47-r10 libtool-1.4.1-r10 automake-1.7.2 gettext-0.11.5 I have emerged GNOME. It was broken (see original report). Then I have updated following without any effect to glib: portage-2.0.47-r10 -> portage-2.0.49-r20 libtool-1.4.1-r10 -> libtool-1.4.3-r1 automake-1.7.2 -> automake-1.7.5-r2 gettext-0.11.5 -> sys-devel/gettext-0.12.1 Then I have updated again: libtool-1.4.3-r1 -> libtool-1.4.3-r3 (UNSTABLE) On my second gentoo box, which is regularly updated to unstable, following grep doesn't find anything, too. > grep /var/tmp/portage /usr/lib/*.la /usr/lib/libgettextlib.la:dependency_libs=' /var/tmp/portage/gettext-0.12.1/image//usr/lib/libintl.la -lc' /usr/lib/libgettextlib.la:libdir='/var/tmp/portage/gettext-0.12.1/image//usr/lib' /usr/lib/libgettextpo.la:dependency_libs=' /var/tmp/portage/gettext-0.12.1/image//usr/lib/libgettextsrc.la /var/tmp/portage/gettext-0.12.1/image//usr/lib/libgettextlib.la /var/tmp/portage/gettext-0.12.1/image//usr/lib/libintl.la -lc' /usr/lib/libgettextpo.la:libdir='/var/tmp/portage/gettext-0.12.1/image//usr/lib' /usr/lib/libgettextsrc.la:dependency_libs=' /var/tmp/portage/gettext-0.12.1/image//usr/lib/libgettextlib.la /var/tmp/portage/gettext-0.12.1/image//usr/lib/libintl.la -lc' /usr/lib/libgettextsrc.la:libdir='/var/tmp/portage/gettext-0.12.1/image//usr/lib' /usr/lib/libglib-2.0.la:libdir='/var/tmp/portage/glib-2.2.3/image//usr/lib' /usr/lib/libgobject-2.0.la:dependency_libs=' /var/tmp/portage/glib-2.2.3/image//usr/lib/libglib-2.0.la' /usr/lib/libgobject-2.0.la:libdir='/var/tmp/portage/glib-2.2.3/image//usr/lib' /usr/lib/libid3tag.la:libdir='/var/tmp/portage/libid3tag-0.15.0b/image//usr/lib' /usr/lib/libintl.la:libdir='/var/tmp/portage/gettext-0.12.1/image//usr/lib' Re-emerging gettext and glib does not help. Now I have discovered, that emerging new libtool isn't enough (at least for glib, for gnome-vfs probably yes). This is from glib install phase: make[2]: Entering directory `/var/tmp/portage/glib-2.2.3/work/glib-2.2.3/glib/libcharset' /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DLIBDIR=\"/var/tmp/portage/glib-2.2.3/image//usr/lib\" -pthread -march=i686 -mmmx -O3 -Os -pipe -Wall -c localcharset.c And later while linking any application: libtool: link: warning: library `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../..//libgobject-2.0.la' was moved. libtool: link: warning: library `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../..//libglib-2.0.la' was moved. libtool: link: warning: library `/usr/lib/libgobject-2.0.la' was moved. libtool: link: warning: library `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../..//libgobject-2.0.la' was moved. libtool: link: cannot find the library `/var/tmp/portage/glib-2.2.3/image//usr/lib/libglib-2.0.la' I have tried to locate the source of problem. It seems, that the bug is basically in portage, which uses deprecated style for einstall() (bug 37782). Second there is libtool, which now has work-around for this bug (libtool-*-portage.patch). There must be any missing dependence, but I haven't any idea, what it is.
After some investigations, I have no idea about this bug, except: - Installation was done over NFS mounted root, and some time disparity issues could cause recompilation/relinking during installation. - Over NFS, forcing DESTDIR installation instead of old style einstall() has fixed this problem (see patch attached to bug 37782, the same effect has replacing einstall with make DESTDIR=${D} install in ebuild).
this bug itself seems non-reproducable. the issues at the root of this should be fixed over time, but thats discussed in another bug. I'm closing this one.
