| Summary: | valgrind 3.1.1 does not build on i386-linux with gcc 4.1 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | felix-kde |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | njn |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version First Reported In: | 3.1.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
Oddly enough we don't deliberately ship non-building code. In fact we even try building it on a range of machines before we ship it - certainly it builds on all my machines including FC5 boxes using gcc 4.1. Not that I see how this can anything to do with the gcc version is use - it is more likely to be a configure problem I would have thought. For the record, you seem to be missing a huge number of flags from that command line - on my machine it looks like: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind-debug/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT valgrind-launcher.o -MD -MP -MF ".deps/valgrind-launcher.Tpo" -c -o valgrind-launcher.o `test -f 'launcher.c' || echo './'`launcher.c; \ Obviously that is an amd64 machine, but x86 should be similar. So not only are you missing lots of -I switches but also lots of -W switches. In fact it looks like the whole of CFLAGS and CPPFLAGS have vanished which is very odd indeed - I can't currently see a mechanism for causing that to happen. Are you passing any switches to configure? Do you have CFLAGS or anything similar set in your environment? I normally have CFLAGS set, but when the error occurred, I assumed it had something to do with that, so I unset CFLAGS, scratch-extracted and configured valgrind again, and hit the same issue again. I also tried creating a build directory and running ../configure from there (instead of calling ./configure from inside the source tree), but that worked even less. I also suspected that my configure or automake would be called by the build process, but that turned out to be not true. Funnily, if I enter coregrind, and run make -n there, I can see that only launcher.c and m_debuglog.c are missing all these flags, not vg_preloaded.c, which would be compiled after that. What make version is known to work? I have make 3.81, maybe that is too bleeding edge? Or maybe my /bin/sh is too new? It's bash 3.1. When I run this, the build succeeds in coregrind: make CFLAGS='-I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"x86-linux\"" -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -m32 -mpreferred-stack-boundary=2 -O -g ' This sounds like some problems I've seen with older automakes, eg. automake-1.7. But then the problem seems to be with autoconf. Anyway, I'm closing crashing and similar bugs that are more than two years old. If you still see this problem with Valgrind 3.4.1 please reopen the bug report. Thanks. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |
./configure works, but make then fails with: make[3]: Entering directory `/tmp/valgrind-3.1.1/coregrind' make -C ../VEX pub/libvex_guest_offsets.h make[4]: Entering directory `/tmp/valgrind-3.1.1/VEX' make[4]: `pub/libvex_guest_offsets.h' is up to date. make[4]: Leaving directory `/tmp/valgrind-3.1.1/VEX' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT launcher.o -MD -MP -MF ".deps/launcher.Tpo" -c -o launcher.o launcher.c; \ then mv -f ".deps/launcher.Tpo" ".deps/launcher.Po"; else rm -f ".deps/launcher.Tpo"; exit 1; fi In file included from launcher.c:48: pub_core_debuglog.h:50:64: error: pub_tool_basics.h: No such file or directory [and then lots of parse errors] Adding an -I so that this include file is found fails with another file missing. Adding another -I so that that include file is also found fails with "Unknown OS". It looks to me as if the build process is thoroughly hosed. Isn't i386-linux the main platform for valgrind? How can something as basic as this fail? I have had build issues with over 50% of the valgrind versions so far, and always had to patch around them. I would appreciate if you'd rather not ship than to ship versions that don't build. My kernel is 2.6.16, and glibc is 2.4, and my gcc is 4.1. My make is 3.81.