Valgrind fails at configure stage if glibc2.14 is installed. Googling it a bit, I found several distros applying a patch[1] to valgrind's configure files to accept this version of glibc. Could you apply it to gentoo too? (or at least have a block to glibc-2.14 if you don't want to apply this patch) [1]: http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg260577.html Reproducible: Always
I forgot posting Compile output: (...) checking the GLIBC_VERSION version... unsupported version 2.14 configure: error: Valgrind requires glibc version 2.2 - 2.13 !!! Please attach the following file when seeking support: !!! /var/tmp/portage/dev-util/valgrind-3.6.1-r1/work/valgrind-3.6.1/config.log * ERROR: dev-util/valgrind-3.6.1-r1 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 3153: Called econf * ebuild.sh, line 561: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of 'emerge --info =dev-util/valgrind-3.6.1-r1', * the complete build log and the output of 'emerge -pqv =dev-util/valgrind-3.6.1-r1'. * The complete build log is located at '/var/log/portage/dev-util:valgrind-3.6.1-r1:20110808-000527.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-util/valgrind-3.6.1-r1/temp/environment'. * S: '/var/tmp/portage/dev-util/valgrind-3.6.1-r1/work/valgrind-3.6.1'
(In reply to comment #0) > Valgrind fails at configure stage if glibc2.14 is installed. Googling it a bit, > I found several distros applying a patch[1] to valgrind's configure files to > accept this version of glibc. > Could you apply it to gentoo too? (or at least have a block to glibc-2.14 if > you don't want to apply this patch) > > [1]: > http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg260577.html > > Reproducible: Always I'll look at the patch, but I'll probably go with the block because glibc-2.14 has *lots* of problems. At this point, I don't know what the fate of 2.14 will be, but I'm won't be surprised if it gets skipped over by many distros.
Okay I added the patch. Its doesn't break any < glibc-2.14 stuff and valgrind might work under 2.14, so this can't hurt. Its in with valgrind-3.6.1-r2. Please test and report back to this bug. If it does work, we have one less blocker.
Ok, It compile good, I am recompiling glibc with debugging symbols as per bug #214065 and I'll report it back when done.
I tested it with 2 simple cases, one wrong and one good: test1.c: int main() { int* a=new int(8); //... //delete a; return 0; } g++ -ggdb -m64 test1.c -o test Darkness stormbyte # valgrind ./test ==12986== Memcheck, a memory error detector ==12986== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==12986== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==12986== Command: ./test ==12986== ==12986== ==12986== HEAP SUMMARY: ==12986== in use at exit: 4 bytes in 1 blocks ==12986== total heap usage: 1 allocs, 0 frees, 4 bytes allocated ==12986== ==12986== LEAK SUMMARY: ==12986== definitely lost: 4 bytes in 1 blocks ==12986== indirectly lost: 0 bytes in 0 blocks ==12986== possibly lost: 0 bytes in 0 blocks ==12986== still reachable: 0 bytes in 0 blocks ==12986== suppressed: 0 bytes in 0 blocks ==12986== Rerun with --leak-check=full to see details of leaked memory ==12986== ==12986== For counts of detected and suppressed errors, rerun with: -v ==12986== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) AND test2.c: int main() { int* a=new int(8); //... delete a; return 0; } g++ -ggdb -m64 test2.c -o test Darkness stormbyte # valgrind ./test ==13015== Memcheck, a memory error detector ==13015== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==13015== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==13015== Command: ./test ==13015== ==13015== ==13015== HEAP SUMMARY: ==13015== in use at exit: 0 bytes in 0 blocks ==13015== total heap usage: 1 allocs, 1 frees, 4 bytes allocated ==13015== ==13015== All heap blocks were freed -- no leaks are possible ==13015== ==13015== For counts of detected and suppressed errors, rerun with: -v ==13015== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) So I think it is working properly with glibc 2.14, I'¡ll close it as fixed.
