| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
![]()
This section:
Blog postings by Operational Dynamics partners and staff
Use the links at top left for a consolidated feed of all the posts made on this
site.
Please note the disclaimer at the bottom of this page.
Mon, 14 Nov 2005
An ebuild for GCJ-4
For some time now I’ve been working on trying to get GCJ 4.x.y going on my machine. I run Gentoo which usually implies that I have rapid access to the latest of anything I need. The exception is GCC; being a system upon which one compiles just about everything from source, the system compiler is the one thing that really, really needs to work. So I am happily running gcc-3.4.3 which is fine, except that I really want gcj-4 for my Java development work.
A while back I posted about some linking issues I was running in to. An update on that: Over the past few months, the guys at Red Hat in Toronto finally figured out that in addition to all the the LD_LIBRARY_PATH nonsense and -Wl,-rpath= stuff I was hacking away with, the traditional Java -Djava.library.path= would work with GCJ. [In fact, it appears that it is necessary to do so to talk to the System.loadLibrary() calls].
But I still needed a modern GCJ to compile with. I’ve been working with Karl Trygve Kalleberg and others about figuring out an ebuild that would install GCJ without getting in the way of the system’s primary GCC install. I’ve long since figured out building GCC manually, but I wanted an ebuild to use the large collection of libraries that the Gentoo compiler team had already worked out for figuring out tarball names, fetching, patching and what not. So over the last couple days I gave it another go. Success!
This time I wrote an ebuild that uses the toolchain eclass for src_unpack() which has lots of magic. I didn’t use it for src_compile() as it was a little to hard to constrain its configure to behave with the $PREFIX I wanted, but I was able to pull a few useful tidbits.
I have called my ebuild gcj-jdk. It installs to /opt/gcj-jdk which goes nicely alongside /opt/sun-jdk-1.4.2.04 (also vaguely following the naming conventions that Red Hat is using) I wonder if version number or at least -4 or -4.1 would be a good idea… and SLOTing? One thing I have not done is try to do the java-gcj-compat thing the Fedora guys did (scripts that are wrappers that emulate java and javac) — as I told #gentoo-java last night, someone else is welcome to grab that and add it — but from where I sit gcj -C is a tricky beast (and gcj -c && gcj --main are even more complex); just assuming it and gij are a drop in replacement for a Real Java VM is asking for trouble.
I used 4.1.0_beta20051105 which is the most recent snapshot as of last week, but I had to use --disable-java-awt (and for good measure disabled the other GTK/glib/cairo stuff) … being a java-gnome hacker I surely don’t need AWT but for whatever reason --enable-java-awt=gtk was causing the build to break.
Release early, release often… so here you go: gcj-jdk-4.1.0_beta20051105. It’ll want a recent binutils (I needed ~x86) and a recent glibc as well. Use at own risk!
Things that still need doing:
- figure out which patches in
files/are actually needed - make sure that it really is not interfering or interacting with
gcc-config - decide on a destination naming convention (
/opt/gcj-jdk-4.1?/opt/gcj-4?) - try and trim the install down [2 seconds after
./configurefires off it mentions that it’s decided to buildfortranandobjcas well ascandc++and java. C and C++ are probably unavoidable, but the first two? Dependencies probably need trimming as well. java-configintegration ifjavaandjavacwrappers get put in?
Comments welcome to gentoo-java
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile

