[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |4.9.0 Known to fail||4.8.5 --- Comment #30 from Richard Biener --- Fixed for 4.9.0.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Jakub Jelinek changed: What|Removed |Added Target Milestone|4.8.4 |4.8.5 --- Comment #29 from Jakub Jelinek --- GCC 4.8.4 has been released.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #28 from Yury Gribov --- (In reply to Paul H. Hargrove from comment #26) > (In reply to Yury Gribov from comment #25) > > Can we close this? > > Just tried to build the released 4.8.3 and still see the original problem > (see error messages below). Same is true at the tip of the gcc-4_8-branch > in svn (at r216525). > > However, 4.9.1 is fine. Right, I fixed this in 4.9 and never bothered to backport to 4.8.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #27 from Daniel Richard G. --- Likewise confirmed on the same Woody system from comment #5: 4.9.1 bootstraps fine, 4.8.3 still has the bug. (Oddly enough, the first configure run in the 4.9.1 bootstrap has the message "checking for libsanitizer support... yes") Given the target milestone, I presume there's going to be a 4.8.4?
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #26 from Paul H. Hargrove --- (In reply to Yury Gribov from comment #25) > Can we close this? Just tried to build the released 4.8.3 and still see the original problem (see error messages below). Same is true at the tip of the gcc-4_8-branch in svn (at r216525). However, 4.9.1 is fine. So, please don't close if 4.8.x is still open to bug fixes. If 4.8. is closed, then this bug can be closed too. -Paul libtool: compile: /home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/./gcc/xgcc -shared-libgcc -B/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/./gcc -nostdinc++ -L/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libstdc++-v3/src -L/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../libsanitizer/sanitizer_common -I ../../../../libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/i686-pc-linux-gnu -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -g -O0 -D_GNU_SOURCE -MT sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc -fPIC -DPIC -o .libs/sanitizer_linux.o ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 'void __sanitizer::internal__exit(int)': ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11: error: '__NR_exit_group' was not declared in this scope syscall(__NR_exit_group, exitcode); ^ make[4]: *** [sanitizer_linux.lo] Error 1 make[4]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libsanitizer/sanitizer_common' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libsanitizer' make[2]: *** [all-stage1-target-libsanitizer] Error 2 make[2]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD' make: *** [all] Error 2
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #25 from Yury Gribov --- Can we close this?
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Richard Biener changed: What|Removed |Added Target Milestone|4.8.3 |4.8.4 --- Comment #24 from Richard Biener --- GCC 4.8.3 is being released, adjusting target milestone.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #23 from Yury Gribov --- Can we close this one?
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #22 from Yury Gribov --- (In reply to Paul H. Hargrove from comment #21) > Do I need to test other branches too? No, I don't think so.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #21 from Paul H. Hargrove --- A build from svn trunk (r207062) completed w/o problems. I see: Configuring in i686-pc-linux-gnu/libsanitizer followed later by checking for necessary platform features... no So the added configure check appears to have functioned as intended. Do I need to test other branches too? -Paul
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #20 from Paul H. Hargrove --- (In reply to Yury Gribov from comment #19) > Paul, could you check if libsanitizer is now auto-disabled on your system > and close the bug in that case? Probably can't get to this until next week. However, I've added this to my TODO list. -Paul
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #3 from Paul H. Hargrove --- (In reply to Kostya Serebryany from comment #1) > Sorry for the breakages, but we are unable to monitor build failures on old > kernels unless someone sets up a regular testing (build bot) with such kernels > for upstream code. This error is from a private "build bot" I've now got set up to perform daily builds of the gupc branch in SVN (see http://gcc.gnu.org/projects/gupc.html). As changes are merged from the trunk to that branch I will notice any build failures and I report them to the GCC Bugzilla if/when I can reproduce them in the trunk or recent snapshot (eg bug 55989) or in a release (as with this bug). Otherwise they are reported to the GUPC team. I am configuring with --disable-libsanitizer right now, but will remove that when/if this bug is resolved such that I can build again. (In reply to Jakub Jelinek from comment #2) > If you don't have __NR_exit_group, your kernel very likely doesn't have the > rest of NPTL support either (so e.g. __NR_futex), so I'm surprised this is > the only error. This is an old Red Hat "2.4.21-60.ELsmp" kernel that contains various bits that Red Hat backported. So, the unistd.h has __NR_fuxtex but not __NR_exit_group. I can't say for sure that futex works, however, as there is no NPTL version of libpthread on the system. For my own purposes, there is no need to make libsanitizer work on this platform. So, if that is not possible I'd like to see configure probe for each of the syscall numbers (and prctl constants as in bug 55989) and then automatically disable building the sanitizer code if any are missing. I don't like current the build-is-broken-by-default situation.
