Dalibor Topic wrote: >Kiyo Inaba wrote: >> I found it can be extended until major classpath resync on Jan of >> 2007 if I revert the mod for 'kaffe/kaffevm/baseClasses.c'. The change >> made in 'baseClasses.c' (v 1.76) is reorder the invocation of >> initialization (initializeSecurity and initThreads). I have no clear >> idea whether this reorder is really needed or not, but I guess this >> modification should be reverted. > >It was needed to make Classpath's java.util.zip implementation work. The >commit was > >2006-08-09 Dalibor Topic <[EMAIL PROTECTED]> ... >Basically, during the initialization of security code, the Classpath zip >implementation ends up triggering use of thread local variables, and >that requires that the threading system is already initialized for it to >work.
I noticed this log, just after I sent the previous mail. And your explanation is understandable. >> On the other hand, snap 060803 can not be compiled on arm/linux because >> of 'pthread_support.o' does not contain any external symbols and linking >> reports several 'undefined symbol' errors. I guess this is because of >> some (tricky) 'ifdef' in boehm gc package, but I did not found a way >> to fix. Others tackling this is very welcome. > >My current results with boehm-gc are a bit across the map (i386-linux, >boehm-gc 6.8, different compilers, CVS head). This report is very interesting for me. I tested boehm with three systems. 1) i386, gcc version 3.2 20020903, Red Hat Linux 8.0 3.2-7 2) i386, gcc version 3.2.3 20030502, FC5 3) i386, gcc version 4.1.1 20060525, FC5 If I use CVS head, and boehm-gc 6.8, they all fail. Testing HWA generates nothing :-< Could you guess any reason why it happens? And also, are there any hint why 'undefined symbols' occurs on arm/linux? Kiyo _______________________________________________ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe