Note to Jakub: Before you do your usual "toss out Scott's bugs", this is NOT the same as bug 114347. valigrind 3.1.0 failed to emerge on my system with the following errors: ar clq libvex.a priv/ir/irdefs.o priv/ir/irmatch.o priv/ir/iropt.o priv/main/vex_main.o priv/main/vex_globals.o priv/main/vex_util.o priv/host-x86/hdefs.o priv/host-amd64/hdefs.o priv/host-arm/hdefs.o priv/host-ppc32/hdefs.o priv/host-x86/isel.o priv/host-amd64/isel.o priv/host-arm/isel.o priv/host-ppc32/isel.o priv/host-generic/h_generic_regs.o priv/host-generic/h_generic_simd64.o priv/host-generic/reg_alloc2.o priv/guest-generic/g_generic_x87.o priv/guest-generic/bb_to_IR.o priv/guest-x86/ghelpers.o priv/guest-amd64/ghelpers.o priv/guest-arm/ghelpers.o priv/guest-ppc32/ghelpers.o priv/guest-x86/toIR.o priv/guest-amd64/toIR.o priv/guest-arm/toIR.o priv/guest-ppc32/toIR.o mv -f libvex.a libvex_x86_linux.a make[4]: Leaving directory `/var/tmp/portage/valgrind-3.1.0/work/valgrind-3.1.0/VEX' x86_64-pc-linux-gnu-gcc -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -O2 -march=opteron -pipe -fno-pie -Wno-long-long -Wdeclaration-after-statement -o memcheck-x86-linux -static -Wl,-defsym,valt_load_address=0x70000000 -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-T,../valt_load_address_x86_linux.lds memcheck_x86_linux-mac_leakcheck.o memcheck_x86_linux-mac_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mac_shared.o memcheck_x86_linux-mc_translate.o ../coregrind/libcoregrind_x86_linux.a ../VEX/libvex_x86_linux.a -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/./libgcc.a when searching for -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libgcc.a when searching for -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/./libgcc.a when searching for -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libgcc.a when searching for -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status make[3]: *** [memcheck-x86-linux] Error 1 make[3]: Leaving directory `/var/tmp/portage/valgrind-3.1.0/work/valgrind-3.1.0/memcheck' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/valgrind-3.1.0/work/valgrind-3.1.0/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/valgrind-3.1.0/work/valgrind-3.1.0' make: *** [all] Error 2 My system is: Portage 2.0.53 (default-linux/amd64/2005.1/no-multilib, gcc-3.4.4, glibc-2.3.6-r1, 2.6.14-gentoo x86_64) ================================================================= System uname: 2.6.14-gentoo x86_64 AMD Opteron(tm) Processor 246 Gentoo Base System version 1.12.0_pre11 dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.16 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=opteron -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=opteron -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://gentoo.mirrors.pair.com/ ftp://gentoo.mirrors.pair.com/ http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/scott/projects/ebuilds" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acl alsa apache2 arts audiofile avi berkdb bitmap-fonts browserplugin bzip2 cdr crypt cups curl doc dvd eds effects emboss encode esd exif expat fam ffmpeg firefox flac font-server foomaticdb fortran gd gdbm gif gimpprint glut gmp gnome gpm grammar gstreamer gtk gtk2 guile hal idn imagemagick imlib ipv6 jpeg junit kde lcms libwww lm-sensors lua lzw lzw-tiff mad math mikmod mjpeg mng motif mozilla mozsvg mp3 mpeg ncurses nls nptl ogg oggvorbis openal opengl pam pcre pdf pdflib perl plotutils plugin png povray ppds python qt quicktime readline samba sdk sdl slang smp spell ssl svg tcltk tcpd tetex theora thesaurus threads tiff truetype truetype-fonts type1 type1-fonts udev usb userlocales vorbis wmf xml xml2 xmms xpm xscreensaver xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Oops, nm me
Have you remerged/upgraded gcc in the mean time? Is this still an issue right now?
(In reply to comment #2) > Have you remerged/upgraded gcc in the mean time? Is this still an issue right > now? I emerge GCC 4.0.2 some time back, and the problem persists (I reported the error while running GCC 3.4.4). I just tried emerging valgrind again, with the same failure.
(In reply to comment #0) [snip] > x86_64-pc-linux-gnu-gcc -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes > -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes > -Wmissing-declarations -O2 -march=opteron -pipe -fno-pie -Wno-long-long > -Wdeclaration-after-statement -o memcheck-x86-linux -static > -Wl,-defsym,valt_load_address=0x70000000 -nodefaultlibs -nostartfiles -u _start > -m32 -Wl,-T,../valt_load_address_x86_linux.lds > memcheck_x86_linux-mac_leakcheck.o memcheck_x86_linux-mac_malloc_wrappers.o > memcheck_x86_linux-mc_main.o memcheck_x86_linux-mac_shared.o > memcheck_x86_linux-mc_translate.o ../coregrind/libcoregrind_x86_linux.a > ../VEX/libvex_x86_linux.a -lgcc > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: > skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/./libgcc.a when > searching for -lgcc [/snip] The command invoked has -m64 and -m32 and -m32 comes last, building a 32-bit binary, while libgcc afaik is only built 64-bit. I unfortunately do not know where the -m32 is coming from though.
Created attachment 80322 [details, diff] really hackishly ugly temporary quickfix Ok, i think i found out a bit more about valgrind today :) Apparently, valgrind assumes that when it's running on amd64 it will be able to compile it's libs for x86 as well, but this fails on the no-multilib profile due to the 32-bit libs not being built (ok this is my working assumption here, please correct me if i'm wrong). The attached patch is just a quick band-aid for Scott to try out, the proper fix would be to add a switch to configure to tell it to not build 32-bit code on amd64 and activate that switch in the ebuild for the no-multilib case. Unfortunately, my autoconf-fu is not good enough yet to produce that patch, so this is all i can offer at the moment.
Created attachment 80364 [details] ebuild with the fix for amd64 no-multilib Valgrind svn has a fix for this already, configure --enable-only64bit. Unfortunately some other things seem to have changed in the build system as well, so until the next version fixes this problem, the current hackish fix might suffice. This ebuild applies the ugly workaround on amd64 no-multilib -- does this fix your problem, Scott?
Created attachment 80365 [details, diff] valgrind-3.1.0-amd64-nomultilib-uglyfix.patch
Marco, have you been able to check if the patch worked for you? If not I'll wait for Scott to confirm.
Yes, the patch appears to solve my problem. Thanks! My apologies for being slow in repsonding; I've been doing a lot of traveling.
(In reply to comment #8) > Marco, have you been able to check if the patch worked for you? > If not I'll wait for Scott to confirm. Sorry for not giving more info about this earlier, i have been testing this patch on an amd64-nomultilib install running under qemu, and there valgrind compiled with this patch but did not run correctly (triggered an assertion in valgrind, e.g. when running valgrind on /bin/ls or hello-world). Just now i've also tested this on my normal amd64-multilib install (by making the patch apply unconditionally and not just for nomultilib) and it compiles and seems to run fine. So, i guess i can write this one off as a qemu error if everything compiles and runs fine for Scott.
My thanks to both of you. I just checked in the fix.
