Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=80322) [details]
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 an attachment (id=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 an attachment (id=80365) [details]
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.