> If you're seeing the difference between the tip of 4.0 and mainline,
> perhaps something is going wrong with the 4.0 configure check, such
> that this feature isn't being enabled?
My snapshot of branch-4.0 pre-dates the change you described.
> > Should I static link with a newer glibc (I'm assuming I can do that
without
> > changing my system glibc) to see if that fixes the problem?
> Yes.
OK. I think the following commands are right to compile and link $2.java
using a specific GLIBC (built from latest release). It seems to work for
very simple programs - no abort unless you remove the asterisked arguments
(i.e. use my system glibc). There's still something funny going on, though,
because java Throwable.printStackTrace doesn't print the right thing and AWT
programs go into an infinite loop. I can't get the resulting binaries to
run in gdb (say "run" and it sits there until I kill gdb), so I don't know
where the AWT programs are hanging, other than that my printf at the start
of _Jv_Throw repeatedly prints, and the constructor for java.awt.Frame
(first time it tries to load the AWT Toolkit, I guess) never returns.
export LD_LIBRARY_PATH=/var/local/gcc/tip_20051115-dwarf2/lib
/var/local/gcc/tip_20051115-dwarf2/bin/gcj -v -g -O2 -c -o $2.o $2.java
/var/local/gcc/tip_20051115-dwarf2/bin/gcj
--verbose
--main=$2
-o $2.bin
* -L/var/local/glibc/2.3.5/lib
-static
-static-libgcc
-save-temps
$2.o
libgcjx.o
-lstdc++
-L.
-lX11
* -Wl,--dynamic-linker=/var/local/glibc/2.3.5/lib/ld-linux.so.2
(libgcjx.o is just everything from lib-gnu-awt-xlib.a in a single
relocatable object file)
Example of a program that works fine, static or dynamic:
import java.util.Properties;
class props
{
static public void main(String args[])
{
Properties props;
props = System.getProperties();
props.list(System.out);
}
}
Example of one that doesn't:
public class Throw
{
public static void main (String[] args)
{
try
{
throw new Exception("This is an exception");
}
catch (Throwable t)
{
t.printStackTrace ();
}
}
}
Running Throw, static build, with glibc 2.4.5, I get:
java.lang.Exception: This is an exception
at java.lang.VMThrowable.fillInStackTrace (Unknown Source)
at java.lang.VMThrowable.fillInStackTrace (Unknown Source)
With my system glibc, static build, same thing, but it aborts on exit.
With my system glibc, dynamic build, I get:
java.lang.Exception: This is an exception
<<No stacktrace available>>
I haven't managed to get dynamic building with glibc 2.3.5 to work. The
following command produces an executable that says it doesn't exist when you
try to run it:
/var/local/gcc/tip_20051115-dwarf2/bin/gcj
--verbose
--main=$2
-Dawt.toolkit=gnu.awt.xlib.XToolkit
-g
-o $2.bin
-L/var/local/glibc/2.3.5/lib
-Wl,--dynamic-linker=/var/localWglibc/2.3.5/lib/ld-linux.so.2
$2.java
With my branch-4.0 snapshot and either my system glibc or 2.3.5, static
Throw.bin produces this nice output:
java.lang.Exception: This is an exception
at Throw.main(java.lang.String[]) (/home/scott/javaTests/Throw.java:7)
at gnu.java.lang.MainThread.call_main()
(/home/scott/javaTests/../../../gcc/libjava/gnu/java/lang/natMainThread.cc:4
7)
at gnu.java.lang.MainThread.run()
(/home/scott/javaTests/../../../gcc/libjava/gnu/java/lang/MainThread.java:10
5)
With my branch-4.0 snapshot, dynamic link with my system glibc, Throw.bin
produces this output, which is nearly as nice:
java.lang.Exception: This is an exception
at Throw.main(java.lang.String[]) (/home/scott/javaTests/Throw.java:7)
at gnu.java.lang.MainThread.call_main()
(/var/local/gcc/branch-4.0/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run()
(/var/local/gcc/branch-4.0/lib/libgcj.so.6.0.0)
