public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* cvs build problem with 2.95
@ 2004-04-17 14:35 Baurjan Ismagulov
  2004-04-18  0:16 ` Daniel Jacobowitz
  2004-04-20 16:42 ` Andrew Cagney
  0 siblings, 2 replies; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-17 14:35 UTC (permalink / raw)
  To: gdb

Hello,

I'm trying to build the latest cvs with gcc 2.95 on a Debian woody/sid
system. Compilation of tcl/generic/tclPipe.c fails at the line 281 with
an error of "storage size of `waitStatus' isn't known". The variable is
declared as "WAIT_STATUS_TYPE waitStatus", which expands to "union
wait". NO_SYS_WAIT_H is set, and sys/wait.h doesn't get included from
tcl/unix/tclUnixPort.h.

configure invoked from make in one of subdirectories says "checking for
sys/wait.h... no". An excerpt from tcl/unix/config.log is given below. I
am not sure why gcc -E should return a non-zero exit status in case of
warnings. Besides, I've tried to reproduce the problem by preprocessing
the sample from config.log with a confdefs.h from libiberty/config.log;
the sample compiled without problems and gcc -E returned 0.

So, the questions:

1. How should I correct this problem? I want to compile the latest cvs.

2. Where is the correct confdefs.h? I want to be able to reproduce
   configure tests.

Thanks in advance,
Baurjan.

Here is the excerpt from tcl/unix/config.log:

configure:2578: checking for sys/wait.h
configure:2588: gcc-2.95 -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/asm/sigcontext.h:4,
                 from /usr/include/bits/sigcontext.h:28,
                 from /usr/include/signal.h:326,
                 from /usr/include/sys/wait.h:30,
                 from configure:2584:
/usr/include/linux/compiler.h:17: warning: `__attribute_used__' redefined
/usr/include/sys/cdefs.h:195: warning: this is the location of the previous definition
configure: failed program was:
#line 2583 "configure"
#include "confdefs.h"
#include <sys/wait.h>

I don't see why this should fail. cpp-2.95(1) doesn't say anything about
the exit status. gcc-2.95(1) states that it should return 0 unless there
are errors or -Werror is given and there are warnings.

And here is the output from make:

gcc-2.95 -c -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -I../../../gdb-20040415.orig/tcl/unix/../generic -I../../../gdb-20040415.orig/tcl/unix -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_SYS_WAIT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DSTATIC_BUILD=1 -DPEEK_XCLOSEIM=1 -DHAVE_SYS_IOCTL_H=1         -DTCL_SHLIB_EXT=\".so\" ../../../gdb-20040415.orig/tcl/unix/../generic/tclPipe.c
In file included from /usr/include/asm/sigcontext.h:4,
                 from /usr/include/bits/sigcontext.h:28,
                 from /usr/include/signal.h:326,
                 from ../../../gdb-20040415.orig/tcl/unix/../generic/../unix/tclUnixPort.h:45,
                 from ../../../gdb-20040415.orig/tcl/unix/../generic/tclPort.h:27,
                 from ../../../gdb-20040415.orig/tcl/unix/../generic/tclPipe.c:17:
/usr/include/linux/compiler.h:17: warning: `__attribute_used__' redefined
/usr/include/sys/cdefs.h:195: warning: this is the location of the previous definition
../../../gdb-20040415.orig/tcl/unix/../generic/tclPipe.c: In function `TclCleanupChildren':
../../../gdb-20040415.orig/tcl/unix/../generic/tclPipe.c:281: storage size of `waitStatus' isn't known
../../../gdb-20040415.orig/tcl/unix/../generic/tclPipe.c:281: warning: unused variable `waitStatus'
make[2]: *** [tclPipe.o] Fehler 1
make[2]: Leaving directory `/mnt/hda5/ibr/src/gdb-20040415-295/tcl/unix'
make[1]: *** [all] Fehler 2

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-17 14:35 cvs build problem with 2.95 Baurjan Ismagulov
@ 2004-04-18  0:16 ` Daniel Jacobowitz
  2004-04-18 14:16   ` Baurjan Ismagulov
  2004-04-20 16:42 ` Andrew Cagney
  1 sibling, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2004-04-18  0:16 UTC (permalink / raw)
  To: gdb

On Sat, Apr 17, 2004 at 03:53:54PM +0200, Baurjan Ismagulov wrote:
> Hello,
> 
> I'm trying to build the latest cvs with gcc 2.95 on a Debian woody/sid
> system. Compilation of tcl/generic/tclPipe.c fails at the line 281 with
> an error of "storage size of `waitStatus' isn't known". The variable is
> declared as "WAIT_STATUS_TYPE waitStatus", which expands to "union
> wait". NO_SYS_WAIT_H is set, and sys/wait.h doesn't get included from
> tcl/unix/tclUnixPort.h.
> 
> configure invoked from make in one of subdirectories says "checking for
> sys/wait.h... no". An excerpt from tcl/unix/config.log is given below. I
> am not sure why gcc -E should return a non-zero exit status in case of
> warnings. Besides, I've tried to reproduce the problem by preprocessing
> the sample from config.log with a confdefs.h from libiberty/config.log;
> the sample compiled without problems and gcc -E returned 0.
> 
> So, the questions:
> 
> 1. How should I correct this problem? I want to compile the latest cvs.
> 
> 2. Where is the correct confdefs.h? I want to be able to reproduce
>    configure tests.

Fix your headers.  Your <linux/compiler.h> is bad.  I don't know what
you're running, but it looks like you grabbed an old version of
linux-kernel-headers from Debian/sid - get a newer one.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-18  0:16 ` Daniel Jacobowitz
@ 2004-04-18 14:16   ` Baurjan Ismagulov
  2004-04-18 15:20     ` Daniel Jacobowitz
  0 siblings, 1 reply; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-18 14:16 UTC (permalink / raw)
  To: gdb

Hello, Daniel!

On Sat, Apr 17, 2004 at 10:35:53AM -0400, Daniel Jacobowitz wrote:
> Fix your headers.  Your <linux/compiler.h> is bad.  I don't know what
> you're running, but it looks like you grabbed an old version of
> linux-kernel-headers from Debian/sid - get a newer one.

Yes, this fixes it. Thank you!


Now I've got another problem:

g++-2.95 -DPACKAGE=\"sidcomp\" -DVERSION=\"0.1\" -I. -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/.. -I../../../include -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/../../../include -I../../../../bfd -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/../../../../include -g -O2 -Wp,-MD,.deps/arm-semsw.pp -c  -fPIC -DPIC ../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/arm-semsw.cxx -o .libs/arm-semsw.lo
g++-2.95: Internal compiler error: program cc1plus got fatal signal 9
make[6]: *** [arm-semsw.lo] Fehler 1
make[6]: Leaving directory `/mnt/hda5/ibr/src/gdb-20040415-295/sid/component/cgen-cpu/arm7t'

gcc 3.3.3 gives the same message at the same file. This was actually why
I wanted to try 2.95. I've updated gcc, cpp and g++ packages, and can
still stably reproduce this. I suspect that I should file a bug against
gcc, but before that I wish to have this working. Any ideas?


With kind regards,
Baurjan.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-18 14:16   ` Baurjan Ismagulov
@ 2004-04-18 15:20     ` Daniel Jacobowitz
  2004-04-18 16:13       ` Baurjan Ismagulov
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2004-04-18 15:20 UTC (permalink / raw)
  To: gdb

On Sun, Apr 18, 2004 at 04:10:15PM +0200, Baurjan Ismagulov wrote:
> Hello, Daniel!
> 
> On Sat, Apr 17, 2004 at 10:35:53AM -0400, Daniel Jacobowitz wrote:
> > Fix your headers.  Your <linux/compiler.h> is bad.  I don't know what
> > you're running, but it looks like you grabbed an old version of
> > linux-kernel-headers from Debian/sid - get a newer one.
> 
> Yes, this fixes it. Thank you!
> 
> 
> Now I've got another problem:
> 
> g++-2.95 -DPACKAGE=\"sidcomp\" -DVERSION=\"0.1\" -I. -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/.. -I../../../include -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/../../../include -I../../../../bfd -I../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/../../../../include -g -O2 -Wp,-MD,.deps/arm-semsw.pp -c  -fPIC -DPIC ../../../../../gdb-20040415.orig/sid/component/cgen-cpu/arm7t/arm-semsw.cxx -o .libs/arm-semsw.lo
> g++-2.95: Internal compiler error: program cc1plus got fatal signal 9
> make[6]: *** [arm-semsw.lo] Fehler 1
> make[6]: Leaving directory `/mnt/hda5/ibr/src/gdb-20040415-295/sid/component/cgen-cpu/arm7t'
> 
> gcc 3.3.3 gives the same message at the same file. This was actually why
> I wanted to try 2.95. I've updated gcc, cpp and g++ packages, and can
> still stably reproduce this. I suspect that I should file a bug against
> gcc, but before that I wish to have this working. Any ideas?

Nope.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-18 15:20     ` Daniel Jacobowitz
@ 2004-04-18 16:13       ` Baurjan Ismagulov
  2004-04-18 22:56         ` Daniel Jacobowitz
  0 siblings, 1 reply; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-18 16:13 UTC (permalink / raw)
  To: gdb

On Sun, Apr 18, 2004 at 10:16:43AM -0400, Daniel Jacobowitz wrote:
> > gcc 3.3.3 gives the same message at the same file. This was actually why
> > I wanted to try 2.95. I've updated gcc, cpp and g++ packages, and can
> > still stably reproduce this. I suspect that I should file a bug against
> > gcc, but before that I wish to have this working. Any ideas?
> 
> Nope.

Which revisions of gcc, g++ and cpp are you using (I suppose you don't
experience these problems)?

With kind regards,
Baurjan.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-18 16:13       ` Baurjan Ismagulov
@ 2004-04-18 22:56         ` Daniel Jacobowitz
  2004-04-19  2:45           ` Baurjan Ismagulov
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2004-04-18 22:56 UTC (permalink / raw)
  To: gdb

On Sun, Apr 18, 2004 at 05:22:06PM +0200, Baurjan Ismagulov wrote:
> On Sun, Apr 18, 2004 at 10:16:43AM -0400, Daniel Jacobowitz wrote:
> > > gcc 3.3.3 gives the same message at the same file. This was actually why
> > > I wanted to try 2.95. I've updated gcc, cpp and g++ packages, and can
> > > still stably reproduce this. I suspect that I should file a bug against
> > > gcc, but before that I wish to have this working. Any ideas?
> > 
> > Nope.
> 
> Which revisions of gcc, g++ and cpp are you using (I suppose you don't
> experience these problems)?

I've never seen the problem you describe.

9 is SIGKILL.  That suggests the problem has nothing to do with your
compiler, and everything to do with your system resource limits, or
kernel.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-18 22:56         ` Daniel Jacobowitz
@ 2004-04-19  2:45           ` Baurjan Ismagulov
  2004-04-19 13:24             ` Jim Blandy
  0 siblings, 1 reply; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-19  2:45 UTC (permalink / raw)
  To: gdb

[-- Attachment #1: mutt-burundai-14491-11 --]
[-- Type: text/plain, Size: 734 bytes --]

Hello, Daniel!

On Sun, Apr 18, 2004 at 12:13:41PM -0400, Daniel Jacobowitz wrote:
> 9 is SIGKILL.  That suggests the problem has nothing to do with your
> compiler, and everything to do with your system resource limits, or
> kernel.

Ah, yes, this was OOM; thank you! 256MB RAM + 128MB swap had worked for
gdb 6.0 compilation, that is why I didn't think about this. Adding 256MB
swap fixed the problem, albeit with intensive thrashing. What in this
file makes gcc consume 350MB of virtual memory 8) , according to top? Is
it an essential part of gdb? In other words, can I build a "minimal" gdb
without it? I'm going to compile various versions for testing, and I
wanted to apply patches on clean trees.

With kind regards,
Baurjan.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-19 13:24             ` Jim Blandy
@ 2004-04-19 12:43               ` Baurjan Ismagulov
  2004-04-19 18:32                 ` Daniel Jacobowitz
  0 siblings, 1 reply; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-19 12:43 UTC (permalink / raw)
  To: gdb

Hello, Jim!

On Mon, Apr 19, 2004 at 01:41:12AM -0500, Jim Blandy wrote:
> >From what you've posted, it doesn't seem that you actually want the
> simulator; why not just drop it?

Yes, I'm recompiling gdb to see whether --disable-sim --disable-sid
--disable-targets makes any difference. But I still would like to know
the options to build the minimal configuration -- just for "break main;
run"; is there any documentation on all supported configure options, at
least for 6.1?

With kind regards,
Baurjan.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-19  2:45           ` Baurjan Ismagulov
@ 2004-04-19 13:24             ` Jim Blandy
  2004-04-19 12:43               ` Baurjan Ismagulov
  0 siblings, 1 reply; 13+ messages in thread
From: Jim Blandy @ 2004-04-19 13:24 UTC (permalink / raw)
  To: Baurjan Ismagulov; +Cc: gdb


Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr> writes:
> On Sun, Apr 18, 2004 at 12:13:41PM -0400, Daniel Jacobowitz wrote:
> > 9 is SIGKILL.  That suggests the problem has nothing to do with your
> > compiler, and everything to do with your system resource limits, or
> > kernel.
> 
> Ah, yes, this was OOM; thank you! 256MB RAM + 128MB swap had worked for
> gdb 6.0 compilation, that is why I didn't think about this. Adding 256MB
> swap fixed the problem, albeit with intensive thrashing. What in this
> file makes gcc consume 350MB of virtual memory 8) , according to top? Is
> it an essential part of gdb? In other words, can I build a "minimal" gdb
> without it? I'm going to compile various versions for testing, and I
> wanted to apply patches on clean trees.

The file you're compiling is part of SID, the simulator, not GDB.  SID
contains a lot of really huge machine-generated files, of which
asm-semsw.cxx is one.  I think that's the file that actually
implements the instruction set of the ARM.

From what you've posted, it doesn't seem that you actually want the
simulator; why not just drop it?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-19 12:43               ` Baurjan Ismagulov
@ 2004-04-19 18:32                 ` Daniel Jacobowitz
  2004-04-20 16:34                   ` Baurjan Ismagulov
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2004-04-19 18:32 UTC (permalink / raw)
  To: gdb

On Mon, Apr 19, 2004 at 10:37:55AM +0300, Baurjan Ismagulov wrote:
> Hello, Jim!
> 
> On Mon, Apr 19, 2004 at 01:41:12AM -0500, Jim Blandy wrote:
> > >From what you've posted, it doesn't seem that you actually want the
> > simulator; why not just drop it?
> 
> Yes, I'm recompiling gdb to see whether --disable-sim --disable-sid
> --disable-targets makes any difference. But I still would like to know
> the options to build the minimal configuration -- just for "break main;
> run"; is there any documentation on all supported configure options, at
> least for 6.1?

There aren't configuration options that make a large difference in the
size of GDB, though you may want --disable-tui --disable-gdbtk.

None of the options you mention above do anything, AFAIK.  I recommend
deleting the sid directory.  You can not build without the sim
directory.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-19 18:32                 ` Daniel Jacobowitz
@ 2004-04-20 16:34                   ` Baurjan Ismagulov
  0 siblings, 0 replies; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-20 16:34 UTC (permalink / raw)
  To: gdb

Hello, Daniel!

On Mon, Apr 19, 2004 at 09:24:57AM -0400, Daniel Jacobowitz wrote:
> There aren't configuration options that make a large difference in the
> size of GDB, though you may want --disable-tui --disable-gdbtk.
> 
> None of the options you mention above do anything, AFAIK.  I recommend
> deleting the sid directory.  You can not build without the sim
> directory.

The former speeded up the build by 2 minutes. And the latter reduced the
compilation time from 2.5 hours to 23 minutes! This makes the 2 minutes
10% :) . Thanks much for the tip!

As to the options: I've found them via google and thought a bit of
voodoo building doesn't hurt if I don't have anything else :) . I would
expect that they cause an error message if they are not supported; I
didn't think they could silently do nothing. But seriously, some pieces
of information would have helped me; if you are interested in including
it either on the web site or in the distribution, I can share what I
have. It's not too much, but I think the stuff like supported platforms,
resource and package requirements, etc. could save others' time, too.

With kind regards,
Baurjan.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-17 14:35 cvs build problem with 2.95 Baurjan Ismagulov
  2004-04-18  0:16 ` Daniel Jacobowitz
@ 2004-04-20 16:42 ` Andrew Cagney
  2004-04-21  0:44   ` Baurjan Ismagulov
  1 sibling, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2004-04-20 16:42 UTC (permalink / raw)
  To: Baurjan Ismagulov; +Cc: gdb

Have a look at the page:
	http://www.gnu.org/software/gdb/current/
for how to check out _just_ GDB.  Looking over your problems you appear 
to have checked out a lot more than you actually need (were there 
woody/sid specific instructions that you were following?).

Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: cvs build problem with 2.95
  2004-04-20 16:42 ` Andrew Cagney
@ 2004-04-21  0:44   ` Baurjan Ismagulov
  0 siblings, 0 replies; 13+ messages in thread
From: Baurjan Ismagulov @ 2004-04-21  0:44 UTC (permalink / raw)
  To: gdb

Hello, Andrew!

On Tue, Apr 20, 2004 at 12:39:51PM -0400, Andrew Cagney wrote:
> Have a look at the page:
> 	http://www.gnu.org/software/gdb/current/
> for how to check out _just_ GDB.  Looking over your problems you appear 
> to have checked out a lot more than you actually need (were there 
> woody/sid specific instructions that you were following?).

Oh, and I was wondering why it was getting so big after update -dP :) !
I did checkout gdb+dejagnu (I used the page you refer to), but have not
payed attention to the update notice. Thanks for the tip!

With kind regards,
Baurjan.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2004-04-20 22:33 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-17 14:35 cvs build problem with 2.95 Baurjan Ismagulov
2004-04-18  0:16 ` Daniel Jacobowitz
2004-04-18 14:16   ` Baurjan Ismagulov
2004-04-18 15:20     ` Daniel Jacobowitz
2004-04-18 16:13       ` Baurjan Ismagulov
2004-04-18 22:56         ` Daniel Jacobowitz
2004-04-19  2:45           ` Baurjan Ismagulov
2004-04-19 13:24             ` Jim Blandy
2004-04-19 12:43               ` Baurjan Ismagulov
2004-04-19 18:32                 ` Daniel Jacobowitz
2004-04-20 16:34                   ` Baurjan Ismagulov
2004-04-20 16:42 ` Andrew Cagney
2004-04-21  0:44   ` Baurjan Ismagulov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).