A fresh CVS (from last night) configured with default options (only --prefix) builds but the resulting gcj doesn't work. Linking this "hello world" program: public class Hello { public static void main (String[] args) { System.err.println("Hello!"); } } yields: gcj -o Hello --main=Hello Hello.java /usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used symbol _sqrt used from dynamic library /usr/lib/libm.dylib(sqrt970.o) not from earlier dynamic library /Users/bothner/GNU/install-gcc/lib/libgcj.6.dylib(w_sqrt.o) Adding -Wl,-bind_at_load yields an executable without complaint, but running that executable just hangs.
Does it hang, or just really slow to start up. For me it takes 14seconds to run this pogram (yes that slow, the problem is related to the dynamic loader on Mac OS X 10.3, it is fixed I hear on 10.4) on a 1.5GHz G4.
(In reply to comment #1) One more note this was a 5 day old compiler but that should not matter.
Todays gcc builds and runs this hello fine :) The difference I have here is the linking stage of libstdc++ and libgcj which I do with -dynamiclib -single_module. Without these modifications in ltcf-** we really have to wait that long until the result comes over. [wolfram:objdir/powerpc-apple-darwin7.7.0/libjava] andreast% time ./hello Hello! 0.780u 0.060s 0:01.68 50.0% 0+0k 0+0io 0pf+0w On a G4/1.5GHz with full mauve testsuite load, the above mentioned :) Configured with: /Volumes/src/gcc/gcc-cvs/gcc/configure --prefix=/Volumes/src/gcc/gcc-cvs/testbin --enable-languages=c,c++,java --enable-java-awt=gtk --enable-gtk-cairo --enable-libgcj-multifile --disable-checking Thread model: posix gcc version 4.0.0 20050111 (experimental) in reply to comment #1, yes it does run with tiger much faster. Also we can run awt and swing apps based on gtk. Unless Apple updates dylib we have no chance to have it better on 10.3.x :( I even do not know if it would be possible.
Indeed, it just takes forever: About 40+ seconds on my 1Gz G4 PowerBook. Linking with -Wl,-bind_at_load doesn't make much difference. I thought it worked before (I don't consider 40 seconds start-up time "working") but perhaps I'm mistaken. Andreast wrote: "Todays gcc builds and runs this hello fine". I'm unclear this means there was a change/fix in gcc, in how you configured/built gcc, or how you compiled/linked the application.
(In reply to comment #4) > Indeed, it just takes forever: About 40+ seconds on my 1Gz G4 PowerBook. > Linking with -Wl,-bind_at_load doesn't make much difference. You have to link libgcj with -single_module to get the speed up. This is a dyld (dynamic loader aka ld.so) problem and not really a java problem. > I thought it worked before (I don't consider 40 seconds start-up time "working") > but perhaps I'm mistaken. The start up time comes from looking up symbols in the dynamic library and it is really a bug in dyld and the only work around I know of is to link libgcj with -single_module, I can post a patch for that but that will take a while because there are more important things with respect with the release of GCC than the slow start-up time of gcj on Pather (Tiger it is fixed).
Created attachment 7929 [details] link libgcj with -single_module
I simply meant I did not test the previous ones. My cable connection dropped. I attached my hackerish ltcf** diff. You may try and see if it gives you a speed up.
This was fixed on somewhere between the 10th and 11th. By one of the patches listed in: http://gcc.gnu.org/ml/gcc-regression/2005-01/txt00012.txt The current time for Hello World is: Hello! 0.760u 0.110s 0:01.53 56.8% 0+0k 1+1io 0pf+0w