NEW: jamvm-1.4.0+classpath-0.19 for i386

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

NEW: jamvm-1.4.0+classpath-0.19 for i386

Frederick C. Druseikis-2
Greetings,

Ports for JamVM and GNU Classpath (tested on i386) are available on:

  http://druseikis.com/OpenBSD/ports/classpath-0.19-port-20051127.tar.gz
  http://druseikis.com/OpenBSD/ports/jamvm-1.4.0-port-20051127.tar.gz
  http://druseikis.com/OpenBSD/ports/freetype2-port-20051127.tar.gz

Notes:

(1) Freetype2 is a dependency for Classpath-0.19.  Install it first. The Freetype2 port does not include the freetype documentation nor does it make any effort to be consistent with the exiting freetype 1.x port.  More work needed here -- comments and suggestions welcome.

(2) Install Classpath next; it has dependencies for other obsd packages and their ports.  The Java code is compiled with Jikes.

(3) This GNU Classpath port has a minor build problem with it: namely, soft links to shared libs need to be created to satisfy JNI declarations.  These are in the makefile.  I do the build this way:

cd /usr/ports/mystuff/classpath-0.19
sudo make build fake post-fake install

(The post-fake target is mine.  The Fake Framework doc explains the special cases, but none of the things I tried seem to work.  I could patch classpath's makefiles to construct the links to the shared libs but have been trying to avoid that; Suggestions welcome here too.)

(4) Install JamVM last; the port assumes you will be installing classpath; glibj.zip will be found without mentioning it on the CLASSPATH environment var or with -classpath flag.

(5) JamVM has powerpc, arm, X86_64 support, which I have not tested.  It might work! (The interpreter has been run on linux an darwin on these archs.) JamVM is supposed to be 64-bit clean.  It uses posix threads.

(6) You must specify -classpath /usr/local/share/classpath/glibj.zip explicitly on Jikes compiles (along with any other build dependencies on your CLASSPATH.)

(7) The JamVM port has a patch to correct a GC bug that will be fixed in JamVM 1.4.1; this is needed to run serious apps.

I have run ant-1.6.5 with it using the binary from apache.org -- not the apache-ant obsd port, which tries to bring in Sun Java 1.3 :P

Comments and suggestions welcome!

Regards,
Fred




Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Jacob Meuser
On Sun, Nov 27, 2005 at 10:50:12PM -0500, Frederick C Druseikis wrote:
> Greetings,
>
> Ports for JamVM and GNU Classpath (tested on i386) are available on:
>
>   http://druseikis.com/OpenBSD/ports/classpath-0.19-port-20051127.tar.gz
>   http://druseikis.com/OpenBSD/ports/jamvm-1.4.0-port-20051127.tar.gz
>   http://druseikis.com/OpenBSD/ports/freetype2-port-20051127.tar.gz


just looking at classpath for the moment.

use the freetype from X.  the pkgconfig file for this is
${X11BASE}/lib/pkgconfig/xft.pc.  you will have to patch configure
to make pkg-config look for xft instead of freetype2, and add
${X11BASE}/lib/pkgconfig to PKG_CONFIG_PATH in CONFIGURE_ENV.

please look at LOCALBASE and X11BASE in bsd.port.mk(5).  do
not hardcode '/usr/local' or '/usr/X11R6' into a port.

why are you specifying AUTOMAKE_VERSION and AUTOCONF_VERSION
if you aren't using automake or autoconf?

the way you specified BUILD_DEPENDS, you will be stuck depending
on specific versions of these packages, even if new ones go
into the ports tree.  you should not specify the actual package
name in packages-specs for BUILD_DEPENDS.

wouldn't java be a more appropriate category than devel?

as far as the version numbers for the modules, tell the classpath
developers to look into using the -avoid-version libtool flag.
if they are hardcoding unversioned module names, they should be
using this to build the modules.


and some general stuffs:

please roll port tarballs from at most 1 directory above the actual
port.

port directories do not have version numbers.  sometimes there
may be foo/bar and foo/bar2 or some such, but those only exist if
there is good reason to have two "generations" of a package in
the ports tree.

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Jacob Meuser
On Sun, Nov 27, 2005 at 09:52:50PM -0800, Jacob Meuser wrote:

> as far as the version numbers for the modules, tell the classpath
> developers to look into using the -avoid-version libtool flag.
> if they are hardcoding unversioned module names, they should be
> using this to build the modules.

looking into this more, this can be fixed in configure.
change the '-version-info ${LIBVERSION}' to '-avoid-version'
in the CLASSPATH_MODULE declaration.

it seems the classpath devs are relying on libtool to create
symlinks.  OpenBSD is not the only OS on which libtool does not
create a libfoo.so -> libfoo.so.0.0 symlink.  using the
-avoid-version flag is the right way to get unversioned modules,
and supplying -version-info is most definitely _not_ the way
to get unversioned modules.

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Aleksander Piotrowski
In reply to this post by Jacob Meuser
Jacob Meuser <[hidden email]> wrote:

> to make pkg-config look for xft instead of freetype2, and add
> ${X11BASE}/lib/pkgconfig to PKG_CONFIG_PATH in CONFIGURE_ENV.

I'm almost sure that pkg-configs searches ${X11BASE}/lib/pkgconfig for
configuration files by default.

Alek
--
- Co to są litery?
- Coś takiego jak mediaglify, tylko że czarne i maleńkie. I wcale się nie
ruszają, są stare, nudne i trudno je czytać. Ale można z nich robić skróty i
długie słowa stają sie krótkie.
 -- Neal Stephenson, Diamentowy Wiek

Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Bernd Ahlers
Aleksander Piotrowski [Mon, Nov 28, 2005 at 09:29:51PM +0100] wrote:
>Jacob Meuser <[hidden email]> wrote:
>
>> to make pkg-config look for xft instead of freetype2, and add
>> ${X11BASE}/lib/pkgconfig to PKG_CONFIG_PATH in CONFIGURE_ENV.
>
>I'm almost sure that pkg-configs searches ${X11BASE}/lib/pkgconfig for
>configuration files by default.
>
devel/pkgconfig/Makefile:

CONFIGURE_ARGS+= \
--with-pc_path=${LOCALBASE}/lib/pkgconfig:${X11BASE}/lib/pkgconfig

Bernd

Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Jacob Meuser
On Tue, Nov 29, 2005 at 01:08:42AM +0100, Bernd Ahlers wrote:

> Aleksander Piotrowski [Mon, Nov 28, 2005 at 09:29:51PM +0100] wrote:
> >Jacob Meuser <[hidden email]> wrote:
> >
> >> to make pkg-config look for xft instead of freetype2, and add
> >> ${X11BASE}/lib/pkgconfig to PKG_CONFIG_PATH in CONFIGURE_ENV.
> >
> >I'm almost sure that pkg-configs searches ${X11BASE}/lib/pkgconfig for
> >configuration files by default.
> >
> devel/pkgconfig/Makefile:
>
> CONFIGURE_ARGS+= \
> --with-pc_path=${LOCALBASE}/lib/pkgconfig:${X11BASE}/lib/pkgconfig

ah, thanks for the pointer!  I guess I haven't played with pkgconfig
enough in the last 7.5 months ;)

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Frederick C. Druseikis-2
In reply to this post by Jacob Meuser
Jacob Meuser <jakemsr <at> jakemsr.com> writes:

>
> why are you specifying AUTOMAKE_VERSION and AUTOCONF_VERSION
> if you aren't using automake or autoconf?
>

I copied the Makefile from another port I was working on; I was expecting the
worse :)

>
> wouldn't java be a more appropriate category than devel?
>

Yes; I started out thinking that java would be the right category. But:
jdk, jakarta-servletapi, apache-ant. are in devel; jikes and kaffe are in lang;
and fastjar is in archivers.  Go figure.  Majority rules?  It might make send to
put them all under java.

>
> port directories do not have version numbers.  sometimes there
> may be foo/bar and foo/bar2 or some such, but those only exist if
> there is good reason to have two "generations" of a package in
> the ports tree.
>

Good comment; I'm anticipating the need for multiple releases.

Classpath is a moving target.  They've been producing developer release every
two months. Although 0.19 sounds like they are just getting started they are 96%
of the way to a conforming JDK 1.4 class library, and within five mauve tests of
a conforming JDK 1.2.  So I expect to see at least two more classpath developer
releases *before* OpenBSD 3.9.  

On the other side of the coin is the jit/jvm space. There is a very strong push
for jit/jvm developers to operate out of the box with the classpath releases.
Some projects are already there, others are about to catch up. Before  0.19 most
projects did a special classpath integration.  So, for example, you see gcc 3.4
stuck back at something like 0.12; btw gcc 4.1 will take classpath out of the
box soon; cacao-0.93 already does.  Kaffe is getting there (so I hear.)  JamVM
is easy because it already was there.

All this is to say that here's classpath/0.19 and expect classpath/0.20 and
/0.21 about 6 months out, depending on the timing of the jits and jvms.  "Lots
of harmony."

There is also the related issue of parallel installations, which I have not
addressed yet and won't until I get a second jit/jvm in play.


Reply | Threaded
Open this post in threaded view
|

Re: NEW: jamvm-1.4.0+classpath-0.19 for i386

Kurt Miller-3
On Tuesday 29 November 2005 08:05 am, you wrote:

> Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> > why are you specifying AUTOMAKE_VERSION and AUTOCONF_VERSION
> > if you aren't using automake or autoconf?
>
> I copied the Makefile from another port I was working on; I was
> expecting the worse :)
>
> > wouldn't java be a more appropriate category than devel?
>
> Yes; I started out thinking that java would be the right category.
> But: jdk, jakarta-servletapi, apache-ant. are in devel; jikes and
> kaffe are in lang; and fastjar is in archivers.  Go figure.  Majority
> rules?  It might make send to put them all under java.

Your thinking about things wrong. By way of example, if the thing
your porting is an audio application, then it goes into catagory
audio as its first catagory (even if it is written in java). java
can be the second catagory to help with cross refefencing things.

Since all the programming languages are in lang (except for
devel/jdk), I think "CATAGORY = lang java" is right for both jamvm
and classpath.

> > port directories do not have version numbers.  sometimes there
> > may be foo/bar and foo/bar2 or some such, but those only exist if
> > there is good reason to have two "generations" of a package in
> > the ports tree.
>
> Good comment; I'm anticipating the need for multiple releases.
>
> Classpath is a moving target.  They've been producing developer
> release every two months. Although 0.19 sounds like they are just
> getting started they are 96% of the way to a conforming JDK 1.4 class
> library, and within five mauve tests of a conforming JDK 1.2.  So I
> expect to see at least two more classpath developer releases *before*
> OpenBSD 3.9.
>
> On the other side of the coin is the jit/jvm space. There is a very
> strong push for jit/jvm developers to operate out of the box with the
> classpath releases. Some projects are already there, others are about
> to catch up. Before  0.19 most projects did a special classpath
> integration.  So, for example, you see gcc 3.4 stuck back at
> something like 0.12; btw gcc 4.1 will take classpath out of the box
> soon; cacao-0.93 already does.  Kaffe is getting there (so I hear.)
> JamVM is easy because it already was there.
>
> All this is to say that here's classpath/0.19 and expect
> classpath/0.20 and /0.21 about 6 months out, depending on the timing
> of the jits and jvms.  "Lots of harmony."
>
> There is also the related issue of parallel installations, which I
> have not addressed yet and won't until I get a second jit/jvm in
> play.

I still dont see the reason for having mutiple jamvm ports or classpath
ports. If as you say vm's are moving toward decoupling, then one
classpath port should suffice.

can jamvm be built or run without a classpath package installed? It must
have a BUILD_DEPEND and RUN_DEPEND on classpath if not.

You've recevied a lot of feedback so far. Please incorporate it into
new versions of your ports. Look at other ports for examples. The whole
ports tree is full of examples of how to do things right. Make sure you
read the documentation that is available to you like bsd.port.mk(5),
ports(5) and http://www.openbsd.org/porting.html too. It will help you
catch your own mistakes.

-Kurt