public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: libgcj build crashes
  2000-04-01  0:00           ` Godmar Back
@ 2000-04-01  0:00             ` Anthony Green
  0 siblings, 0 replies; 20+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gback; +Cc: gback, mdw, java-discuss

Godmar wrote:
> - is anybody building libgcj on a machine with less than 256MB
>   virtual memory?
> - is anybody building libgcj on a RH5.2 machine?
>   (Matt, how much swap space does your machine have?)

Yes, I've been able to reproduce this failure on my 5.2 machine.

I've also just added a bunch of swap and it's still failing - although
it took a lot longer this time :-)

It looks like a parser bug.  We're continuously looping around
somewhere allocating tree nodes.  More investigation required....

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

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

* gcc bug (Was: libgcj build crashes)
  2000-04-01  0:00 libgcj build crashes Godmar Back
  2000-04-01  0:00 ` Alexandre Petit-Bianco
@ 2000-04-01  0:00 ` Anthony Green
  2000-04-01  0:00   ` Godmar Back
  2000-04-01  0:00 ` libgcj build crashes Matt Welsh
  2 siblings, 1 reply; 20+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gback; +Cc: java-discuss, gcc-bugs

Godmar wrote:
> With the current CVS of both gcc and libgcj, I'm getting the failure
> below when building libgcj.  I'm building on a x86 box; the only option
> specified to both the egcs and the libgcj configure was a --prefix option.

Tonight Alex and I discovered that gcc was miscompiling the compiler.

We've verified this problem in gcc 2.7.2.3, but other notes in the
java-discuss thread imply that the problem continues to exist.  I
think you said your bootstrapped snapshot has the same problem.

gcc/tree.c contains (around line 3147):

  length = sizeof (struct tree_exp);

  if (ggc_p)
    t = ggc_alloc_tree (length);
  else
    {
      t = (tree) obstack_alloc (obstack, length);
      memset ((PTR) t, 0, length);
    }

The compiler recognizes `memset' here and generates inline code.  In
the particular buggy case we discovered, length is 96 but the inlined
code is only clearing out 94 bytes.

This confuses some other part of the compiler, resulting in the
failure you've reported.

As a work-around, try building GCC with -fno-builtin.  The library's
memset will clear all 96 bytes.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

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

* Re: gcc bug (Was: libgcj build crashes)
  2000-04-01  0:00 ` gcc bug (Was: libgcj build crashes) Anthony Green
@ 2000-04-01  0:00   ` Godmar Back
  2000-04-01  0:00     ` Anthony Green
  0 siblings, 1 reply; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: green; +Cc: gback, java-discuss, gcc-bugs

> 
> 
> Godmar wrote:
> > With the current CVS of both gcc and libgcj, I'm getting the failure
> > below when building libgcj.  I'm building on a x86 box; the only option
> > specified to both the egcs and the libgcj configure was a --prefix option.
> 
> Tonight Alex and I discovered that gcc was miscompiling the compiler.
> 
> We've verified this problem in gcc 2.7.2.3, but other notes in the
> java-discuss thread imply that the problem continues to exist.  I
> think you said your bootstrapped snapshot has the same problem.
> 
> gcc/tree.c contains (around line 3147):
> 
>   length = sizeof (struct tree_exp);
> 
>   if (ggc_p)
>     t = ggc_alloc_tree (length);
>   else
>     {
>       t = (tree) obstack_alloc (obstack, length);
>       memset ((PTR) t, 0, length);
>     }
> 
> The compiler recognizes `memset' here and generates inline code.  In
> the particular buggy case we discovered, length is 96 but the inlined
> code is only clearing out 94 bytes.
> 
> This confuses some other part of the compiler, resulting in the
> failure you've reported.
> 
> As a work-around, try building GCC with -fno-builtin.  The library's
> memset will clear all 96 bytes.
> 

Trying to bootstrap with -fno-builtin fails with:

../../egcs/gcc/frame
make[3]: Entering directory `/x/gback/egcs-obj/gcc'
./xgcc -B/opt/local/i686-pc-linux-gnu/bin/ -B./ -I/opt/local/i686-pc-linux-gnu/include -O2   -DIN_GCC    -W -Wall -Wtraditional -O2 -fno-builtin -I./include  -fPIC -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -g -O2 -I. -I../../egcs/gcc -I../../egcs/gcc/config -I../../egcs/gcc/../include \
  -c ../../egcs/gcc/cp/tinfo.cc
cc1plus: warning: Ignoring command line option '-Wtraditional'
../../egcs/gcc/cp/tinfo.cc: In method `bool type_info::operator== (const type_info &) const':
../../egcs/gcc/cp/tinfo.cc:69: implicit declaration of function `int strcmp (...)'
make[3]: *** [tinfo.o] Error 1
make[3]: Leaving directory `/x/gback/egcs-obj/gcc'
make[2]: *** [libgcc2.a] Error 1
make[2]: Leaving directory `/x/gback/egcs-obj/gcc'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/x/gback/egcs-obj/gcc'
make: *** [bootstrap] Error 2

	- Godmar

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

* Re: libgcj build crashes
  2000-04-01  0:00 ` libgcj build crashes Matt Welsh
@ 2000-04-01  0:00   ` Anthony Green
  2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00     ` Godmar Back
  0 siblings, 2 replies; 20+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: mdw; +Cc: gback, java-discuss

Matt wrote:
> I'm seeing this exact crash.

I just did a fresh check out, bootstrap and test run with the
following primitive script and everything worked fine.

This was all on an IA-32 Red Hat 6.1 system.

Then I tried rebuilding libgcj with just the --prefix option and it
also worked fine.  You might want to try running this script and
checking on the results (much) later.


---- cut here ---------------------------------------------------------
#!/usr/bin/expect --

# gcj-test.exp v0.1 - a script for testing the latest and greatest gcj

# Copyright (c) 2000  Red Hat, Inc.
#
# gcj-test.exp is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# gcj-test.exp is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU CC; see the file COPYING.  If not, write to the Free
# Software Foundation, 59 Temple Place - Suite 330, Boston, MA
# 02111-1307, USA.

set prompt "gcj-test$ "
set cvsoptions "-z9"
set toplevel [pwd]

set timeout -1
spawn $env(SHELL)
match_max 100000

# -----------------------------------------------------------------------
# Test for prerequisites

# test for autogen

proc cvs_login { user archive pword } {
    global prompt
    global cvsoptions

    send -- "cvs $cvsoptions -d:pserver:$user:$archive login\r"
    expect -exact "CVS password: "
    send -- "$pword\r"
    expect -exact "$prompt"
}

proc do { cmd } {
    global prompt

    send -- "$cmd\r"
    expect -exact "$prompt"
}

do "export PS1=\"$prompt\""


do "export GCJTESTDIR=`pwd`/`date +\"%Y-%m-%d-%H.%M.%S\"`"
do "mkdir \$GCJTESTDIR"
do "cd \$GCJTESTDIR"
do "rm -rf install && mkdir install && mkdir install/bin"
do "export PATH=`(cd install/bin && pwd)`:\$PATH"

do "cd $toplevel"

# -----------------------------------------------------------------------
# Make sure we have dejagnu installed

if ![file exists tools/bin/runtest] {

    log_file dejagnu.log

    do "mkdir tools"

    do "rm -rf dejagnu && mkdir dejagnu && cd dejagnu"
    send -- "ftp gcc.gnu.org\r"
    expect -exact "):"
    send -- "anonymous\r"
    expect -exact "Password:"
    send -- "gcj-tester@somewhere\r"
    expect -exact "ftp> "
    send -- "cd pub/gcc/infrastructure\r"
    expect -exact "ftp> "
    send -- "hash\r"
    expect -exact "ftp> "
    send -- "binary\r"
    expect -exact "ftp> "
    send -- "get dejagnu-19990614.tar.gz\r"
    expect -exact "ftp> "
    send -- "bye\r"
    expect -exact "$prompt"
    
    do "gzip -d < dejagnu-19990614.tar.gz | tar xfv -"
    do "cd dejagnu-19990614"

    # Apply a patch that isn't in the snapshots yet. :-(
    do "cd dejagnu/lib"
    do "cat target.exp | sed -e \"s/\\\$sources \\\$add_flags/\\\$add_flags \\\$sources/g\" > xxx"
    do "mv xxx target.exp"
    do "cd ../.."

    do "./configure --prefix=`(cd ../../tools && pwd)`"
    do "make"
    do "make install"

    do "cd $toplevel"

    log_file
    do "gzip -f -9 dejagnu.log"
}

do "export PATH=`(cd tools/bin && pwd)`:\$PATH"

do "cd \$GCJTESTDIR"

# -----------------------------------------------------------------------
# Build and install the latest & greatest binutils first.

log_file binutils.log

do "rm -rf binutils && mkdir binutils && cd binutils"
cvs_login anoncvs@anoncvs.cygnus.com /cvs/binutils anoncvs
do "cvs $cvsoptions -d:pserver:anoncvs@anoncvs.cygnus.com:/cvs/binutils co binutils"

do "rm -rf build && mkdir build"
do "cd build"
do "../binutils/configure --prefix=`(cd ../../install && pwd)`"
do "make"
do "make install"

log_file
do "gzip -f -9 binutils.log"

# -----------------------------------------------------------------------
# Now that binutils has been built and installed, let's build and 
# install the latest & greatest GCC.

log_file gcc.log

do "cd \$GCJTESTDIR"

do "rm -rf gcc && mkdir gcc && cd gcc"
cvs_login anoncvs@anoncvs.cygnus.com /cvs/gcc anoncvs
do "cvs $cvsoptions -d:pserver:anoncvs@anoncvs.cygnus.com:/cvs/gcc co egcs-java"
do "cvs $cvsoptions -d:pserver:anoncvs@anoncvs.cygnus.com:/cvs/gcc co egcs-g++"
do "cvs $cvsoptions -d:pserver:anoncvs@anoncvs.cygnus.com:/cvs/gcc co egcs-core"

do "rm -rf build && mkdir build"
do "cd build"
do "../egcs/configure --prefix=`(cd ../../install && pwd)` --enable-threads --with-ld=\$GCJTESTDIR/install/bin/ld --with-as=\$GCJTESTDIR/install/bin/as"
do "make bootstrap-lean LANGUAGES=\"c c++ java\""
do "make install LANGUAGES=\"c c++ java\""

log_file
do "gzip -f -9 gcc.log"

# -----------------------------------------------------------------------
# Now that GCC and binutils have been built and installed, let's build
# and install the latest & greatest libgcj.

log_file libgcj.log

do "cd \$GCJTESTDIR"

do "rm -rf libgcj && mkdir libgcj && cd libgcj"
cvs_login anoncvs@anoncvs.cygnus.com /cvs/java anoncvs
do "cvs $cvsoptions -d:pserver:anoncvs@anoncvs.cygnus.com:/cvs/java co libgcj"

do "rm -rf build && mkdir build"
do "cd build"
do "../libgcj/configure --prefix=`(cd ../../install && pwd)` --enable-threads --disable-multilib --enable-fast-character"
do "make"
do "make install"

log_file
do "gzip -f -9 libgcj.log"

log_file runtest.log

do "cd \$GCJTESTDIR"
do "export LD_LIBRARY_PATH=`(cd install/lib && pwd)`:\$LD_LIBRARY_PATH"

do "rm -rf mauve"

cvs_login anoncvs@anoncvs.cygnus.com /cvs/mauve anoncvs
do "cvs $cvsoptions -d:pserver:anoncvs@anoncvs.cygnus.com:/cvs/mauve co mauve"

do "cd libgcj/build/`libgcj/libgcj/config.guess`/libjava/testsuite"

do "export MAUVEDIR=`(cd \$GCJTESTDIR/mauve && pwd)`"
do "export SUN_JAVAC='gcj -C'"
do "make check"

log_file
do "gzip -f -9 runtest.log"

---- cut here ---------------------------------------------------------

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

* Re: libgcj build crashes
  2000-04-01  0:00         ` Anthony Green
@ 2000-04-01  0:00           ` Matt Welsh
  2000-04-01  0:00             ` Godmar Back
  2000-04-01  0:00           ` Godmar Back
  1 sibling, 1 reply; 20+ messages in thread
From: Matt Welsh @ 2000-04-01  0:00 UTC (permalink / raw)
  To: green; +Cc: gback, java-discuss

I built the lates gcj and libgcj and it works fine. I guess the problems
I was seeing may have been in the particular snapshot of egcs that I was
using...

Anthony Green <green@cygnus.com> writes:
> 
> Godmar wrote:
> >  Could it be an incompatibility with binutils, glibc, or the compiler
> > used to bootstrap gcc?
> 
> FYI - binutils was fixed today.  You might want to try the script
> again.
> 
> AG
> 
> -- 
> Anthony Green                                                        Red Hat
>                                                        Sunnyvale, California
> 

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

* Re: libgcj build crashes
  2000-04-01  0:00             ` Godmar Back
  2000-04-01  0:00               ` Godmar Back
@ 2000-04-01  0:00               ` Tom Tromey
  2000-04-01  0:00                 ` Godmar Back
  1 sibling, 1 reply; 20+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back; +Cc: mdw, green, java-discuss

>>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:

Godmar> cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && aclocal
Godmar> cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && automake --foreign Makefile

You probably shouldn't be running automake here.
In your case, you're running the wrong version.

Tom

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

* Re: libgcj build crashes
  2000-04-01  0:00             ` Godmar Back
@ 2000-04-01  0:00               ` Godmar Back
  2000-04-01  0:00               ` Tom Tromey
  1 sibling, 0 replies; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back; +Cc: mdw, green, gback, java-discuss

> 
> > 
> > 
> > I built the lates gcj and libgcj and it works fine. I guess the problems
> > I was seeing may have been in the particular snapshot of egcs that I was
> > using...
> > 
> 
> No kidding.  Btw, the script now fails (apparently much later) with:
> 

I take that back.  The script still fails at the same file, although with
a different error msg now.  Apparently, it doesn't stop if things go wrong.
libgcj.log shows the failure below, which is the same failure I observe when
building w/o the script.  

make[2]: Entering directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava'
make java/lang/ConcreteProcess.class
make[3]: Entering directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava'
javac="gcj -C"; \
$javac -g -L/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava -classpath /x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava:`cd ../../../libgcj/libjava && /bin/pwd` \
  -d /x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava java/lang/ConcreteProcess.java

Cannot allocate 4072 bytes
make[3]: *** [java/lang/ConcreteProcess.class] Error 1
make[3]: Leaving directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava'
make[2]: *** [libgcj.zip] Error 2
make[2]: Leaving directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava'
make: *** [install-target-libjava] Error 2
gcj-test$


Apparently, jc1 runs out of memory (I only have 128 MB phys + 128 MB swap
on the machine I'm building.)  Top shows: 

31654 root      19   0  131M  97M   324 R       0 37.4 77.8   0:05 jc1

before it bails.

	- Godmar

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

* Re: gcc bug (Was: libgcj build crashes)
  2000-04-01  0:00   ` Godmar Back
@ 2000-04-01  0:00     ` Anthony Green
  0 siblings, 0 replies; 20+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gback; +Cc: gback, java-discuss, gcc-bugs

Godmar wrote:
> Trying to bootstrap with -fno-builtin fails with:

This is a bug - the compiler should build with -fno-builtin.  Jason
has kindly offered to fix this.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

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

* Re: libgcj build crashes
  2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00       ` Anthony Green
@ 2000-04-01  0:00       ` Marcus G. Daniels
  1 sibling, 0 replies; 20+ messages in thread
From: Marcus G. Daniels @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back; +Cc: green, mdw, java-discuss

This probably isn't relevant, but I have a different symptom using
the Objective C compiler -- the new garbage collector in GCC crashes
fairly consistently.  An immediate return from ggc_collect avoids the crash.
Of course, the traces that were originally posted looked to be gcj
things..

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

* Re: libgcj build crashes
  2000-04-01  0:00 libgcj build crashes Godmar Back
  2000-04-01  0:00 ` Alexandre Petit-Bianco
  2000-04-01  0:00 ` gcc bug (Was: libgcj build crashes) Anthony Green
@ 2000-04-01  0:00 ` Matt Welsh
  2000-04-01  0:00   ` Anthony Green
  2 siblings, 1 reply; 20+ messages in thread
From: Matt Welsh @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Godmar Back; +Cc: java-discuss

Godmar Back <gback@cs.utah.edu> writes:
> 
> With the current CVS of both gcc and libgcj, I'm getting the failure
> below when building libgcj.  I'm building on a x86 box; the only option
> specified to both the egcs and the libgcj configure was a --prefix option.

I'm seeing this exact crash.

> make[2]: Entering directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
> make java/lang/ConcreteProcess.class
> make[3]: Entering directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
> javac="gcj -C"; \
> $javac -g -L/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava -classpath /x/gback
> /libgcj-obj/i686-pc-linux-gnu/libjava:`cd ../../../libgcj/libjava && /bin/pwd
> ` \
>   -d /x/gback/libgcj-obj/i686-pc-linux-gnu/libjava java/lang/ConcreteProcess.
> java
> gcj: Internal compiler error: program jc1 got fatal signal 11

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

* Re: libgcj build crashes
  2000-04-01  0:00 ` Alexandre Petit-Bianco
@ 2000-04-01  0:00   ` Alexandre Petit-Bianco
  0 siblings, 0 replies; 20+ messages in thread
From: Alexandre Petit-Bianco @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Alexandre Petit-Bianco writes:
> I'm starting a build on my side.

And I don't see anything wrong happening. Here's my configuration:

apbianco@deliverance[~]: uname -a ; cat /etc/issue.net 
Linux deliverance.cygnus.com 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999 i686 unknown

Red Hat Linux release 6.0 (Hedwig)
Kernel 2.2.5-22smp on an i686

What's yours?

./A

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

* Re: libgcj build crashes
  2000-04-01  0:00     ` Godmar Back
@ 2000-04-01  0:00       ` Anthony Green
  2000-04-01  0:00         ` Anthony Green
  2000-04-01  0:00       ` Marcus G. Daniels
  1 sibling, 1 reply; 20+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gback; +Cc: mdw, gback, java-discuss

Godmar wrote:
>  Could it be an incompatibility with binutils, glibc, or the compiler
> used to bootstrap gcc?

Very interesting.  I've reported the problem to
binutils@sourceware.cygnus.com.

The script should really identify and report broken builds.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

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

* Re: libgcj build crashes
  2000-04-01  0:00 libgcj build crashes Godmar Back
@ 2000-04-01  0:00 ` Alexandre Petit-Bianco
  2000-04-01  0:00   ` Alexandre Petit-Bianco
  2000-04-01  0:00 ` gcc bug (Was: libgcj build crashes) Anthony Green
  2000-04-01  0:00 ` libgcj build crashes Matt Welsh
  2 siblings, 1 reply; 20+ messages in thread
From: Alexandre Petit-Bianco @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Godmar Back writes:

> With the current CVS of both gcc and libgcj, I'm getting the failure
> below when building libgcj.  I'm building on a x86 box; the only option
> specified to both the egcs and the libgcj configure was a --prefix option.

Can you make sure that your systems says:

apbianco@deliverance[~]: egrep WITH_FILE <....>/egcs/gcc/tree.def 
DEFTREECODE (EXPR_WITH_FILE_LOCATION, "expr_with_file_location", 'e', 3)

I'm starting a build on my side.

./A

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

* Re: libgcj build crashes
  2000-04-01  0:00   ` Anthony Green
  2000-04-01  0:00     ` Godmar Back
@ 2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00       ` Anthony Green
  2000-04-01  0:00       ` Marcus G. Daniels
  1 sibling, 2 replies; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: green; +Cc: mdw, gback, java-discuss

 Could it be an incompatibility with binutils, glibc, or the compiler
used to bootstrap gcc?

I bootstrapped with a Dec Snapshot, my glibc is 2.0.7-29, my binutils
is 2.9.1


I noticed that the binutils.log created by your test script ended with

gcc -DHAVE_CONFIG_H -I. -I../../binutils/ld -I. -D_GNU_SOURCE -I. -I../../binutils/ld -I../bfd -I../../binutils/ld/../bfd -I../../binutils/ld/../include -I../../binutils/ld/../intl -I../intl  -g -O2 -W -Wall -DLOCALEDIR="\"/x/gback/testgcj/2000-02-03-21.52.25/install/share/locale\""    -g -O2 -W -Wall -c ../../binutils/ld/ldlang.c../../binutils/ld/ldlang.c:2830:34: macro `ALIGN_N' used with too many (3) args
make[2]: *** [ldlang.o] Error 1make[2]: Leaving directory `/x/gback/testgcj/2000-02-03-21.52.25/binutils/build/ld'make[1]: *** [install-recursive] Error 1make[1]: Leaving directory `/x/gback/testgcj/2000-02-03-21.52.25/binutils/build/ld'make: *** [install-ld] Error 2

Thanks,

	- Godmar

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

* Re: libgcj build crashes
  2000-04-01  0:00           ` Matt Welsh
@ 2000-04-01  0:00             ` Godmar Back
  2000-04-01  0:00               ` Godmar Back
  2000-04-01  0:00               ` Tom Tromey
  0 siblings, 2 replies; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: mdw; +Cc: green, gback, java-discuss

> 
> 
> I built the lates gcj and libgcj and it works fine. I guess the problems
> I was seeing may have been in the particular snapshot of egcs that I was
> using...
> 

No kidding.  Btw, the script now fails (apparently much later) with:

checking for a BSD compatible install... /usr/bin/install -c
updating cache ./config.cache
creating ./config.status
creating Makefile
creating gnu/testlet/config.java
make[2]: Entering directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava/testsuite/mauve-build'
Makefile:318: choices: No such file or directory
ok=no; \
if test -f .save-keys && test -f choices && test "`cat .save-keys`" = "libgcj"; then \
  ok=yes; \
fi; \
here=`/bin/pwd`; \
if test "$ok" = no; then \
  echo "libgcj" > .save-keys; \
  cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && /bin/sh choose $here libgcj; \
fi
cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && aclocal
cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && automake --foreign Makefile
automake: configure.in: required file `./depcomp' not found
make[2]: *** [/x/gback/testgcj/2000-02-04-22.49.35/mauve/Makefile.in] Error 1
make[2]: Leaving directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava/testsuite/mauve-build'
FAIL: Mauve build

                === libjava Summary ===

# of expected passes            1
# of unexpected failures        341
# of expected failures          676
make[1]: *** [check-DEJAGNU] Error 1
make[1]: Leaving directory `/x/gback/testgcj/2000-02-04-22.49.35/libgcj/build/i686-pc-linux-gnu/libjava/testsuite'
make: *** [check-am] Error 2
gcj-test$ gzip -f -9 runtest.log
runtest.log: No such file or directory
gcj-test$ 15.380u 2.420s 56:38.86 0.5%  0+0k 0+0io 1152pf+231w

Let me know if you want more information.

	- Godmar

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

* Re: libgcj build crashes
  2000-04-01  0:00       ` Anthony Green
@ 2000-04-01  0:00         ` Anthony Green
  2000-04-01  0:00           ` Matt Welsh
  2000-04-01  0:00           ` Godmar Back
  0 siblings, 2 replies; 20+ messages in thread
From: Anthony Green @ 2000-04-01  0:00 UTC (permalink / raw)
  To: green; +Cc: gback, mdw, gback, java-discuss

Godmar wrote:
>  Could it be an incompatibility with binutils, glibc, or the compiler
> used to bootstrap gcc?

FYI - binutils was fixed today.  You might want to try the script
again.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

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

* Re: libgcj build crashes
  2000-04-01  0:00         ` Anthony Green
  2000-04-01  0:00           ` Matt Welsh
@ 2000-04-01  0:00           ` Godmar Back
  2000-04-01  0:00             ` Anthony Green
  1 sibling, 1 reply; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: green; +Cc: gback, mdw, java-discuss

Another update on the libgcj build failure.

With Anthony's script I verified that 2000-02-07-19.09.03 works 
under RedHat 6.1 (glibc 2.1.2-11, kernel 2.2.12)
while 2000-02-07-11.28.57 and 2000-02-07-21.17.00 still
do not work on my RedHat 5.2 box (glibc 2.0.7, kernel
2.2.12)

The failure is still running out of virtual memory
when compiling ConcreteProcess.java.  Both RH machines
use identical hardware (an elderly Dual PII/350.)

However, I cannot reliably say that it works on the RH 6.1
machine because of the RH version.  The RH 6.1 machine is
configured with 512 M swap space (same physical memory is in both
machines 128M).  My RH5.2 is only configured with 128MB swap space.

So, I guess my questions are:
- is anybody building libgcj on a machine with less than 256MB
  virtual memory?
- is anybody building libgcj on a RH5.2 machine?
  (Matt, how much swap space does your machine have?)

Thanks,

    - Godmar

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

* libgcj build crashes
@ 2000-04-01  0:00 Godmar Back
  2000-04-01  0:00 ` Alexandre Petit-Bianco
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

With the current CVS of both gcc and libgcj, I'm getting the failure
below when building libgcj.  I'm building on a x86 box; the only option
specified to both the egcs and the libgcj configure was a --prefix option.

Thanks,

	- Godmar


make[2]: Entering directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
make java/lang/ConcreteProcess.class
make[3]: Entering directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
javac="gcj -C"; \
$javac -g -L/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava -classpath /x/gback/libgcj-obj/i686-pc-linux-gnu/libjava:`cd ../../../libgcj/libjava && /bin/pwd` \
  -d /x/gback/libgcj-obj/i686-pc-linux-gnu/libjava java/lang/ConcreteProcess.java
gcj: Internal compiler error: program jc1 got fatal signal 11
make[3]: *** [java/lang/ConcreteProcess.class] Error 1
make[3]: Leaving directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
make[2]: *** [libgcj.zip] Error 2
make[2]: Leaving directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava'
make: *** [all-target-libjava] Error 2

(gdb) run java/lang/ConcreteProcess.java -quiet -g -version -fclasspath=/x/gback
/libgcj-obj/i686-pc-linux-gnu/libjava:/x/gback/libgcj/libjava -foutput-class-dir
=/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava -fsyntax-only -femit-class-files 
-o ConcreteProcess.s
Starting program: /opt/local/lib/gcc-lib/i686-pc-linux-gnu/2.96/jc1 java/lang/ConcreteProcess.java -quiet -g -version -fclasspath=/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava:/x/gback/libgcj/libjava -foutput-class-dir=/x/gback/libgcj-obj/i686-pc-linux-gnu/libjava -fsyntax-only -femit-class-files -o ConcreteProcess.s
GNU Java version 2.96 20000203 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 2.96 20000203 (experimental).

Program received signal SIGSEGV, Segmentation fault.
set_java_signature (type=0x835b7ac, sig=0x835b69c)
    at ../../../egcs/gcc/java/typeck.c:706
706       old_sig = TYPE_LANG_SPECIFIC (type)->signature;

#0  set_java_signature (type=0x835b7ac, sig=0x835b69c)
    at ../../../egcs/gcc/java/typeck.c:706
#1  0x805ee5c in add_method (this_class=0x835a73c, access_flags=1, 
    name=0x828a5fc, method_sig=0x835b69c) at ../../../egcs/gcc/java/class.c:609
#2  0x805231b in method_header (flags=1, type=0x0, mdecl=0x835b658, throws=0x0)
    at ./parse.y:3544
#3  0x804e0fa in java_parse () at ./parse.y:1055
#4  0x8072343 in parse_source_file (file=0x835a028)
    at ../../../egcs/gcc/java/jcf-parse.c:735
#5  0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#6  0x8071ce9 in read_class (name=0x831aca4)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#7  0x8071e1f in load_class (class_or_name=0x831aca4, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#8  0x805460c in process_imports () at ./parse.y:5215
#9  0x80530e0 in java_complete_class () at ./parse.y:4157
#10 0x8072350 in parse_source_file (file=0x83177c8)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#11 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#12 0x8071ce9 in read_class (name=0x82f22a0)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#13 0x8071e1f in load_class (class_or_name=0x82f22a0, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#14 0x805460c in process_imports () at ./parse.y:5215
#15 0x80530e0 in java_complete_class () at ./parse.y:4157
#16 0x8072350 in parse_source_file (file=0x82f1e9c)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#17 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#18 0x8071ce9 in read_class (name=0x828f554)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#19 0x8071e1f in load_class (class_or_name=0x828f554, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#20 0x80534e5 in do_resolve_class (class_type=0x82aebbc, decl=0x82aeb2c, 
    cl=0x82aeae0) at ./parse.y:4383
#21 0x80533d0 in resolve_class (class_type=0x82aebbc, decl=0x82aeb2c, 
    cl=0x82aeae0) at ./parse.y:4313
#22 0x80530a1 in jdep_resolve_class (dep=0x82af820) at ./parse.y:4133
#23 0x8053179 in java_complete_class () at ./parse.y:4173
#24 0x8072350 in parse_source_file (file=0x82ad644)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#25 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#26 0x8071ce9 in read_class (name=0x8289c2c)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#27 0x8071e1f in load_class (class_or_name=0x8289c2c, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#28 0x80534a4 in do_resolve_class (class_type=0x82a93c8, decl=0x82a9428, 
    cl=0x82a9344) at ./parse.y:4366
#29 0x80533d0 in resolve_class (class_type=0x82a93c8, decl=0x82a9428, 
    cl=0x82a9344) at ./parse.y:4313
#30 0x80530a1 in jdep_resolve_class (dep=0x82aa030) at ./parse.y:4133
#31 0x8053179 in java_complete_class () at ./parse.y:4173
#32 0x8072350 in parse_source_file (file=0x82a78a8)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#33 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#34 0x8071ce9 in read_class (name=0x82a0874)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#35 0x8071e1f in load_class (class_or_name=0x82a0874, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#36 0x805460c in process_imports () at ./parse.y:5215
#37 0x80530e0 in java_complete_class () at ./parse.y:4157
#38 0x8072350 in parse_source_file (file=0x82a0548)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#39 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#40 0x8071ce9 in read_class (name=0x829d460)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#41 0x8071e1f in load_class (class_or_name=0x829d460, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#42 0x805460c in process_imports () at ./parse.y:5215
#43 0x80530e0 in java_complete_class () at ./parse.y:4157
#44 0x8072350 in parse_source_file (file=0x829c754)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#45 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#46 0x8071ce9 in read_class (name=0x8289e14)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#47 0x8071e1f in load_class (class_or_name=0x8289e14, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#48 0x80534a4 in do_resolve_class (class_type=0x829bfc8, decl=0x829bea4, 
    cl=0x829bdc4) at ./parse.y:4366
#49 0x80533d0 in resolve_class (class_type=0x829bfc8, decl=0x829bea4, 
    cl=0x829bdc4) at ./parse.y:4313
#50 0x80530a1 in jdep_resolve_class (dep=0x829cc48) at ./parse.y:4133
#51 0x8053179 in java_complete_class () at ./parse.y:4173
#52 0x8072350 in parse_source_file (file=0x829bc30)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#53 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#54 0x8071ce9 in read_class (name=0x828f6b8)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#55 0x8071e1f in load_class (class_or_name=0x828f6b8, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#56 0x80534e5 in do_resolve_class (class_type=0x829b458, decl=0x829b334, 
    cl=0x829b254) at ./parse.y:4383
#57 0x80533d0 in resolve_class (class_type=0x829b458, decl=0x829b334, 
    cl=0x829b254) at ./parse.y:4313
#58 0x80530a1 in jdep_resolve_class (dep=0x82964b8) at ./parse.y:4133
#59 0x8053179 in java_complete_class () at ./parse.y:4173
#60 0x8072350 in parse_source_file (file=0x829b0c0)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#61 0x8071ed1 in jcf_parse_source () at ../../../egcs/gcc/java/jcf-parse.c:559
#62 0x8071ce9 in read_class (name=0x8297938)
    at ../../../egcs/gcc/java/jcf-parse.c:481
#63 0x8071e1f in load_class (class_or_name=0x8297938, verbose=0)
    at ../../../egcs/gcc/java/jcf-parse.c:528
#64 0x805460c in process_imports () at ./parse.y:5215
#65 0x80530e0 in java_complete_class () at ./parse.y:4157
#66 0x8072350 in parse_source_file (file=0x828f1d4)
    at ../../../egcs/gcc/java/jcf-parse.c:737
#67 0x807274b in yyparse () at ../../../egcs/gcc/java/jcf-parse.c:867
#68 0x807cda4 in compile_file (
    name=0xbffffd80 "java/lang/ConcreteProcess.java")
    at ../../egcs/gcc/toplev.c:2373
#69 0x8080549 in main (argc=11, argv=0xbffffc44)
    at ../../egcs/gcc/toplev.c:4764


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

* Re: libgcj build crashes
  2000-04-01  0:00   ` Anthony Green
@ 2000-04-01  0:00     ` Godmar Back
  2000-04-01  0:00     ` Godmar Back
  1 sibling, 0 replies; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: green; +Cc: mdw, gback, java-discuss

> 
> Matt wrote:
> > I'm seeing this exact crash.
> 
> I just did a fresh check out, bootstrap and test run with the
> following primitive script and everything worked fine.
> 
> This was all on an IA-32 Red Hat 6.1 system.
> 
> Then I tried rebuilding libgcj with just the --prefix option and it
> also worked fine.  You might want to try running this script and
> checking on the results (much) later.
> 

It's no different with your script.

The tail end of libgcj.log shows:

javac="gcj -C"; \
$javac -g -L/x/gback/testgcj/2000-02-03-21.52.25/libgcj/build/i686-pc-linux-gnu/libjava -classpath /x/gback/testgcj/2000-02-03-21.52.25/libgcj/build/i686-pc-linux-gnu/libjava:`cd ../../../libgcj/libjava && /bin/pwd` \
  -d /x/gback/testgcj/2000-02-03-21.52.25/libgcj/build/i686-pc-linux-gnu/libjava java/lang/ConcreteProcess.java
gcj: Internal compiler error: program jc1 got fatal signal 11
make[3]: *** [java/lang/ConcreteProcess.class] Error 1
make[3]: Leaving directory `/x/gback/testgcj/2000-02-03-21.52.25/libgcj/build/i686-pc-linux-gnu/libjava'
make[2]: *** [libgcj.zip] Error 2
make[2]: Leaving directory `/x/gback/testgcj/2000-02-03-21.52.25/libgcj/build/i686-pc-linux-gnu/libjava'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/x/gback/testgcj/2000-02-03-21.52.25/libgcj/build/i686-pc-linux-gnu/libjava'
make: *** [install-target-libjava] Error 2

This is on x86 with a RH 5.2 with a 2.2.12 kernel.

	- Godmar

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

* Re: libgcj build crashes
  2000-04-01  0:00               ` Tom Tromey
@ 2000-04-01  0:00                 ` Godmar Back
  0 siblings, 0 replies; 20+ messages in thread
From: Godmar Back @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Godmar Back, mdw, green, java-discuss

> 
> >>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:
> 
> Godmar> cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && aclocal
> Godmar> cd /x/gback/testgcj/2000-02-04-22.49.35/mauve && automake --foreign Makefile
> 
> You probably shouldn't be running automake here.
> In your case, you're running the wrong version.
> 

I know that I shouldn't be running automake.  I've learned that the hard way ;-)
Technically, though, it's Anthony's script that's running it.
I cut-and-pasted the contents of the log file.  Note that it's
probably bogus anyway because the script continued despite an earlier 
failure. 

As for the version of automake.  As I understand it, there's no fully working 
version of automake in existence.  All released versions are broken in one 
way or another, and a new release is not in sight because Redhat isn't 
paying you to do work on automake, and it has to come out of your freetime
budget.

The version of automake I'm running is 1.4a.  Technically, there is no version
1.4a --- I think 1.4a is given to any snapshot past version 1.4.  Luckily,
I happen to know which version of automake I'm running.  It's the one blessed
by Alexandre that has the property that it compiles kaffe's .am files without
us getting tripped up by bugs.
It's the version we agreed on using after we got tired tracking down
bugs that came in because different developers regenerated the project's
.in files with whatever version of automake happened to come with their
system.
I know that RedHat 6.0 also comes with a 1.4a version, however, 
that's a different one.  The version I'm using is from
http://www.dcc.unicamp.br/~oliva/snapshots/automake/automake-1.4a-dep-19990816.tar.gz

Maybe it would be a good idea if you also "blessed"  a snapshot of automake
for a specific project, such as libgcj.  Anthony's script could be extended
to first download and build that version before continuing.

	- Godmar

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

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01  0:00 libgcj build crashes Godmar Back
2000-04-01  0:00 ` Alexandre Petit-Bianco
2000-04-01  0:00   ` Alexandre Petit-Bianco
2000-04-01  0:00 ` gcc bug (Was: libgcj build crashes) Anthony Green
2000-04-01  0:00   ` Godmar Back
2000-04-01  0:00     ` Anthony Green
2000-04-01  0:00 ` libgcj build crashes Matt Welsh
2000-04-01  0:00   ` Anthony Green
2000-04-01  0:00     ` Godmar Back
2000-04-01  0:00     ` Godmar Back
2000-04-01  0:00       ` Anthony Green
2000-04-01  0:00         ` Anthony Green
2000-04-01  0:00           ` Matt Welsh
2000-04-01  0:00             ` Godmar Back
2000-04-01  0:00               ` Godmar Back
2000-04-01  0:00               ` Tom Tromey
2000-04-01  0:00                 ` Godmar Back
2000-04-01  0:00           ` Godmar Back
2000-04-01  0:00             ` Anthony Green
2000-04-01  0:00       ` Marcus G. Daniels

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).