while emerging valgrind-2.2.0, Makefile gets generated: ------- coregrind/Makefile:207 --------- bindir = ${exec_prefix}/bin build = i686-pc-linux build_alias = build_cpu = i686 build_os = linux build_vendor = pc datadir = /usr/share exec_prefix = ${prefix} host = i686-pc-linux-gnu host_alias = i686-pc-linux-gnu host_cpu = i686 host_os = linux-gnu host_vendor = pc includedir = ${prefix}/include infodir = /usr/share/info install_sh = /var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0/install-sh libdir = ${exec_prefix}/lib libexecdir = ${exec_prefix}/libexec localstatedir = /var/lib mandir = /usr/share/man mkdir_p = mkdir -p -- . oldincludedir = /usr/include prefix = /usr -------------------------------- note that prefix is defined way after it's used. This is causing VG_LIBDIR to be generated as the temp. portage workdir + /usr/lib... so: -DVG_LIBDIR="\"/var/tmp/portage/valgrind-2.2.0/image//usr/lib/valgrind"\" This appears to only be in the coregrind subdir of the valgrind build. Reproducible: Always Steps to Reproduce: 1. emerge =valgrind-2.2.0 2. 3. Actual Results: build succeed but application can't run: valgrind: failed to load /var/tmp/portage/valgrind-2.2.0/image//usr/lib/valgrind/stage2: No such file or directory Expected Results: build a Makefile with a prefix defined *before* it was used thus using the proper prefix rather than the current directory. Ultimately, it should have generated a valgrind binary that will work. Portage 2.0.50-r11 (default-x86-2004.2, gcc-3.4.1, glibc-2.3.4.20040808-r0, 2.6.5-aa5) ================================================================= System uname: 2.6.5-aa5 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi aim alsa apache2 apm arts audiofile avi berkdb bitmap-fonts bonobo canna cjk crypt cups doc dvd encode esd evo fbcon foomaticdb gd gdbm gif gnome gpm gps gtk gtk2 imagemagick imap imlib innodb jpeg kde libg++ libwww mad mikmod motif mpeg msn mysql ncurses nls oggvorbis opengl oscar oss pam pdflib perl png python qt quicktime readline samba sdl slang spell ssl svga tcltk tcpd truetype usb wmf x11 x86 xml xml2 xmms xorg xprint xv yahoo zlib"
May well have misidentified cause of bad path. When running make manually without portage, the path is set up fine... perhaps in a USE flag?
emerges and runs fine for me, using it since this versions ebuild is out. just emerged again just to be sure I'm using latest ebuild. so I have no clue what might be going wrong for you...
I'm going to mark it worksforme, reopen if you experience and can reproduce the issue
I resynced and re-emerged valgrind today... same thing: valgrind: failed to load /var/tmp/portage/valgrind-2.2.0/image//usr/lib/valgrind/stage2: No such file or directory somewhere in the build a static path of /var/tmp/portage/valgrind-2.2.0/image/ is getting prepended onto a build parameter as that is there the files are going temporarily. Could it be a bug which only arises with a certain USE flag?
Could you provide the invocation command line of configure? You can get to it by interrupting the emerge and checking near the top of the following file: /var/tmp/portage/valgrind-2.2.0/work/valgrind-2.2.0/config.log
I really need more info to do something about this.
Not sure what the issue was but since 2.2.0-r1, this no longer seems to be an issue.
