RE: Contribution of security, crypto, and x-net libraries
>The 'full' implementation areas still need work too! Besides bringing >the APIs up to 5.0 we have some known bugs which I'll be happy to help >fix if the contribution is accepted into svn. > >It seems that you are falling over the stub implementation of >java.math.BigInteger. I'll also volunteer to help to fill those methods >in to get the HARMONY-16 code working. Yes, I understand that it is not 'full' implementation yet and in the beginning we'll have a lot of issues like that, for example, it is not possible to compile some security unit tests because they require java.util.logging package, so I have to exclude them from the build and test suite run. The same for tests that depends on BigInteger class I added them to exclude list for a while. Currently I'm trying to minimize test case that causes JVM hang up. Thanks, Stepan Mishura Intel Managed Runtime Division
Re: [jchevm] Porting JCHEVM to OSX/PPC
David Tanzer wrote: Good Idea, but where would I place that branch? "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"? I don't know what the policy is (probably there isn't one :-) I'd guess anywhere underneath "sandbox" is OK. E.g., you could create harmony/enhanced/branches/sandbox/dtanzer or whatever. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] Porting JCHEVM to OSX/PPC
On Tue, 2005-11-29 at 16:34 -0600, Archie Cobbs wrote: [...] > > I stripped out lots of ELF specific stuff, so my version could be > > interesting for a port to windows too. I just don't want to commit it > > to "trunk" yet because it's completely untested. > > You could create a branch to play with in Subversion. If you do, > I recommend also using svnmerge... http://dellroad.org/svnmerge Good Idea, but where would I place that branch? "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"? I'll look at the rest of the issues later... Cheers, David. -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Jeden Tag vorm Einschlafen des Biosavard-Gesetz. Eh klar, do seid ihr high und happy. -- F. Hoislbauer smime.p7s Description: S/MIME cryptographic signature
Re: [jchevm] Porting JCHEVM to OSX/PPC
David Tanzer wrote: The good news first: it compiles now. The problem I described in the previous mail was that libjc was linked with the option "-module" (so it can be dlopen()ed) and this is not portable. I removed the -module and now it compiles. I stripped out lots of ELF specific stuff, so my version could be interesting for a port to windows too. I just don't want to commit it to "trunk" yet because it's completely untested. You could create a branch to play with in Subversion. If you do, I recommend also using svnmerge... http://dellroad.org/svnmerge @Archie Cobbs: Is the "-module" really important for libjc? If yes we'd have to find a portable solution for this... JC dlopen()s itself in order to access core native code for java.lang, etc. This code in turn accesses core VM functions. It's possible to avoid this; e.g., you could add a special hack in JC's native linker along with a static (and redundant) array of available native functions. This would be easy to do but imposes a maintenance burden because this list must be kept up to date with the functions defined in libjc/native/*.c. To make it compile I left the funtion "_jc_dynamic_invoke(...)" in the file "libjc/arc/ppc/arch_functions.c" empty, but this function is needed to run JCHEVM (it calls C functions and is needed for JNI AFAICS). Maybe somebody with more PPC experience can help me with porting this function from i386. That function essentially does the same thing as libffi (but slightly differently of course :-) You might look at libffi's implementation. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jchevm] Porting JCHEVM to OSX/PPC
The good news first: it compiles now. The problem I described in the previous mail was that libjc was linked with the option "-module" (so it can be dlopen()ed) and this is not portable. I removed the -module and now it compiles. I stripped out lots of ELF specific stuff, so my version could be interesting for a port to windows too. I just don't want to commit it to "trunk" yet because it's completely untested. @Archie Cobbs: Is the "-module" really important for libjc? If yes we'd have to find a portable solution for this... To make it compile I left the funtion "_jc_dynamic_invoke(...)" in the file "libjc/arc/ppc/arch_functions.c" empty, but this function is needed to run JCHEVM (it calls C functions and is needed for JNI AFAICS). Maybe somebody with more PPC experience can help me with porting this function from i386. Cheers, David. On Sat, 2005-11-26 at 11:44 +0100, David Tanzer wrote: > Hi Again. > > Now it compiles, but the linking fails: > > Making all in jc > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -g -O3 -pipe -Wall > -Waggregate-return -Wcast-align -Wchar-subscripts -Wcomment -Wformat - > Wimplicit -Wmissing-declarations -Wmissing-prototypes -Wnested- > externs -Wno-long-long -Wparentheses -Wpointer-arith -Wredundant- > decls -Wreturn-type -Wswitch -Wtrigraphs -Wuninitialized -Wunused - > Wwrite-strings -g -O2 -pthread -o jc main.o ../libjc/libjc.la -ldl - > lpopt -lcrypto -lz -lm > > *** Warning: Linking the executable jc against the loadable module > *** libjc.so is not portable! > ** Warning, lib libjc.so is a module, not a shared library > > ** And there doesn't seem to be a static archive available > ** The link will probably fail, sorry > gcc -g -O2 -g -O3 -pipe -Wall -Waggregate-return -Wcast-align -Wchar- > subscripts -Wcomment -Wformat -Wimplicit -Wmissing-declarations - > Wmissing-prototypes -Wnested-externs -Wno-long-long -Wparentheses - > Wpointer-arith -Wredundant-decls -Wreturn-type -Wswitch -Wtrigraphs - > Wuninitialized -Wunused -Wwrite-strings -g -O2 -o .libs/jc main.o - > pthread ../libjc/.libs/libjc.so -L/sw/lib -ldl /sw/lib/libpopt.dylib / > sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lcrypto -lz -lm > powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread' > /usr/bin/ld: ../libjc/.libs/libjc.so is input for the dynamic link > editor, is not relocatable by the static link editor again > collect2: ld returned 1 exit status > make[1]: *** [jc] Error 1 > make: *** [all-recursive] Error 1 > > Something similar is discussed here: > http://www.cocoadev.com/index.pl?ApplicationLinkingIssues > > Maybe somebody here on this list knows how to handle this. > Cheers, David. > > On Thu, 2005-11-24 at 17:22 +0100, David Tanzer wrote: > > Hi Archie, > > > > Thanks for your help so far. etc/makedist.sh runs now, and I have > > removed some more elf specific stuff from libjc/ (I hope I didn't > > destroy too much ;)). The build now hangs at libjc/gc_root.c where > > _JC_REGISTER_OFFS is used for the first time. AFAICS this relies on > > the i386 registers, so I guess this one will become more tricky to > > port. I'll have a closer look into that over the weekend. > > > > Cheers, David. > > > > On Wed, 2005-11-23 at 11:56 -0600, Archie Cobbs wrote: > > > David Tanzer wrote: > > > > Thanks, your infos brought me a little bit further. Not etc/makedist.sh > > > > fails when it invokes jcjavah for the first time: the > > > > _JC_MUTEX_LOCK(...) > > > > called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll > > > > have a look at this in the next few days. Maybe you have some hints for > > > > me where I could start? > > > > > > Oops, fortunately that's an easy fix.. should be fixed now... > > > svn update and try again. > > > > > > -Archie > > > > > > __ > > > Archie Cobbs *CTO, Awarix* http://www.awarix.com -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies. FORTRAN is for wimp engineers who wear white socks. smime.p7s Description: S/MIME cryptographic signature
RE: failed to use xml formatter on contributions combination
> ah... same stack trace as Ant Bugzilla Report 36733: > http://issues.apache.org/bugzilla/show_bug.cgi?id=36733 Thank you for pointing out to the bug report. I added all jars mentioned in the bug report comments to class path and this resolved the issue. It made possible to use JUnitReport task to generate results summary. Stepan Mishura Intel Managed Runtime Division
