Summary: | Stable portage tree of GNOME is completely broken by /var/tmp/portage references | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Stanislav Brabec <utx> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 37782 | ||
Bug Blocks: |
Description
Stanislav Brabec
2004-01-10 03:40:00 UTC
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. |