harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Harmony Bootstrap JVM <boot...@earthlink.net>
Subject Re: Small problems building under cygwin
Date Fri, 21 Oct 2005 19:12:32 GMT


You hit the nail on the head.  Harmony _will_ need
to ship a jni.h at some point, including platform-specific
extensions, or arrange with somebody like GNU Classpath
to provide it.  But for now, part of what I am trying to
accomplish is a way for people to _not_ depend on
any particular JDK at this early stage of the project.
This is a result of lurking on the dev@ list for the first
couple of months of the project.  I saw much discussion
about class libraries and their relative merits and
thought it would be wise to stick my head in the sand
until the pain got too intense and I had to deal with
the issue.  :-)

In other words, let people use their existing JDK's for
the time being (especially for the compiler and for the
JAR utility, perhaps basic core classes like java.lang.Object),
we'll solve the problem in the form it comes to us
when we have a code base to deal with.  Now, I
don't know if we are yet to that point because I
need to get all the opcodes working, but if someone
knows of an opcode test suite, that would _definitely_
advance the quality of the software and get us closer
to that milestone of needing our own jni.h file(s).

Dan Lydick

-----Original Message-----
From: Tom Tromey <tromey@redhat.com>
Sent: Oct 21, 2005 11:45 AM
To: harmony-dev@incubator.apache.org, Apache Harmony Bootstrap JVM <bootjvm@earthlink.net>
Subject: Re: Small problems building under cygwin

>>>>> "Dan" == Apache Harmony Bootstrap JVM <bootjvm@earthlink.net> writes:

Dan> Another thought about the '__int64' issue.  A friend told
Dan> me a while back that this symbol was typedef'ed in a
Dan> header file called 'stdint.h' on GCC, but this does not
Dan> exist on my Solaris box, and I didn't need it anyway.
Dan> For Linux, I suspect that if you go find this symbol in
Dan> the /usr/include tree, that it will probably appear in
Dan> this file (I _think_ this is the correct name, but I am
Dan> not sure).  Perhaps this is the way to solve the problem
Dan> compiling the JNI code?

Harmony is going to have to ship its own jni.h anyway.  This is part
of a complete JVM.  FWIW there's already one in Classpath.

The jni_md.h part is typically architecture, OS, and compiler
dependent.  That said, maintaining this file is not a big deal.
The actual code in the x86 linux version of the file in Classpath
amounts to 13 lines.


Dan Lydick

View raw message