| Summary: | valgrind 3.1.0 fails to emerge due to incompatible libgcc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Scott Robert Ladd <gentoo> |
| Component: | New packages | Assignee: | Maurice van der Pot (RETIRED) <griffon26> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gentoo-bugzilla, inovick |
| Priority: | High | ||
| Version: | 2005.1 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
really hackishly ugly temporary quickfix
ebuild with the fix for amd64 no-multilib valgrind-3.1.0-amd64-nomultilib-uglyfix.patch |
||
|
Description
Scott Robert Ladd
2005-12-03 18:50:22 UTC
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. |
