Contrary to gdb 7.8, 7.9 fails to compile on 32-bit Solaris: gcc -g -O2 -I. -I/vol/src/gnu/gdb/gdb-7.9/gdb -I/vol/src/gnu/gdb/gdb-7.9/gdb/common -I/vol/src/gnu/gdb/gdb-7.9/gdb/config -DLOCALEDIR="\"/vol/gcc/share/locale\"" -DHAVE_CONFIG_H -I/vol/src/gnu/gdb/gdb-7.9/gdb/../include/opcode -I/vol/src/gnu/gdb/gdb-7.9/gdb/../opcodes/.. -I/vol/src/gnu/gdb/gdb-7.9/gdb/../readline/.. -I../bfd -I/vol/src/gnu/gdb/gdb-7.9/gdb/../bfd -I/vol/src/gnu/gdb/gdb-7.9/gdb/../include -I../libdecnumber -I/vol/src/gnu/gdb/gdb-7.9/gdb/../libdecnumber -I/vol/src/gnu/gdb/gdb-7.9/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -I/usr/include/python2.6 -I/usr/include/python2.6 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Wold-style-definition -Wformat-nonliteral -c -o i386-sol2-nat.o -MT i386-sol2-nat.o -MMD -MP -MF .deps/i386-sol2-nat.Tpo /vol/src/gnu/gdb/gdb-7.9/gdb/i386-sol2-nat.c In file included from /vol/src/gnu/gdb/gdb-7.9/gdb/i386-sol2-nat.c:23:0: /usr/include/sys/procfs.h:24:2: error: #error "Cannot use procfs in the large file compilation environment" make: *** [i386-sol2-nat.o] Error 1 I could track this down as follows: * before, gdb/config.h didn't define _FILE_OFFSET_BITS, now it has #define _FILE_OFFSET_BITS 64 * in gdb 7.8, the `checking for special C compiler options needed for large files' tests in gdb/configure weren't run at all since they were guarded by test "$enable_largefile" != no * enable_largefile was set to no in config/largefile.m4 * in gdb 7.9, the default for $plugins changed from its previous no, so suddenly the largefile support gets enabled again, breaking the gdb build Rainer
Can you confirm whether GDB 7.12 does better? Given that this isn't a regression, I don't think this PR should be blocking for 8.0. In other words, a fix by 8.0 would be great, but we shouldn't block 8.0 because of that (known) issue.
> --- Comment #1 from Joel Brobecker <brobecker at gnat dot com> --- > Can you confirm whether GDB 7.12 does better? I just tried 7.12.1 on i386-pc-solaris2.10: same failure. > Given that this isn't a regression, I don't think this PR should be blocking > for 8.0. In other words, a fix by 8.0 would be great, but we shouldn't block > 8.0 because of that (known) issue. How is this not a regression? Worked in 7.8, broke build in 7.9 pretty much looks like a regression to me ;-) Rainer
> I just tried 7.12.1 on i386-pc-solaris2.10: same failure. Darn... > > > for 8.0. In other words, a fix by 8.0 would be great, but we shouldn't block > > 8.0 because of that (known) issue. > > How is this not a regression? Worked in 7.8, broke build in 7.9 > pretty much looks like a regression to me ;-) It depends on how you define regression, of course. For the purpose of a new release, we only consider the previous version/branch. If the previous release/branch already had the issue, then we no longer consider it blocking, basically because create a new release without the fix wouldn't make things worse for that platform.