>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
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/sandbo
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
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
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
i
> 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 t
