Power PC Build
Eric Richardson
ekrichardson at gmail.com
Fri Jan 2 13:32:24 PST 2009
Andrew,
On Wed, Dec 31, 2008 at 7:46 AM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:
> 2008/12/31 Eric Richardson <ekrichardson at gmail.com>:
> > Andrew,
> >
> > On Mon, Dec 29, 2008 at 11:30 PM, Andrew John Hughes
> > <gnu_andrew at member.fsf.org> wrote:
> >>
> >> 2008/12/30 Eric Richardson <ekrichardson at gmail.com>:
> >> > Michael,
> >> >
> >> > On Mon, Dec 29, 2008 at 3:57 PM, Michael Franz <mvfranz at gmail.com>
> >> > wrote:
> >> >>
> >> >> Andrew,
> >> >>
> >> >> On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes
> >> >> <gnu_andrew at member.fsf.org> wrote:
> >> >> <snip>
> >> >>>
> >> >>> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a
> >> >>> --with-project=bsd option for supporting using the BSD tree in place
> >> >>> of the main JDK7 tree. It just needs testing. I think supporting
> the
> >> >>> use of BSD as an alternate icedTea build is the better solution long
> >> >>> term. All it really needs is someone will to try building on Mac
> >> >>> OS/BSD and to maintain it long-term by supplying us with patches.
> >> >>> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK)
> but
> >> >>> we're certainly open to more contributors and to supporting more
> >> >>> platforms. I'd much prefer this to forking zero support. There are
> >> >>> also other features such as the web plugin, web start support, etc.
> in
> >> >>> IcedTea that may be useful for BSD and Mac OS X users.
> >> >>
> >> >> I made a quick attempt at building icedtea7 on OS X. The autogen.sh
> >> >> fails
> >> >> with the following:
> >> >> onfigure.ac:4: installing `./config.guess'
> >> >> configure.ac:4: installing `./config.sub'
> >> >> configure.ac:2: installing `./install-sh'
> >> >> Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no
> >> >> program
> >> >> or
> >> >> Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible
> >> >> typo)
> >> >> Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program
> or
> >> >> Makefile.am:1227: library has `JTREG' as canonic name (possible typo)
> >> >>
> >> >> Also, I was not able to find IcedTea7 specific instructions. Are
> there
> >> >> any?
> >> >>
> >> >> Michael
> >> >> <snip>
> >> >
> >> > I got this same error but tried configure anyway
> >> >
> >> > ./configure --with-openjdk-home=/Library/Java/Home --enable-zero=yes
> >> > --with-project=bsd
> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
> >> >
> >> >
> --with-alt-jar=/System/LibrarFrameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar
> >> >
> >> > checking for libgcj-4.3.*.jar...
> >> > configure: error: "A LIBGCJ jar was not found."
> >> >
> >>
> >> Either use an OpenJDK/IcedTea build by adding --with-openjdk or
> >> specify --with-libgcj-jar to point to rt.jar.
> >> As I said in my previous email though, the libgcj build will not work
> >> with a non-Classpath/GCJ build environment.
> >> (--with-libgcj-jar is gone from IcedTea6, it will go from 7 when we next
> >> merge).
> >
> > This suggestion was very helpful. The problem using the JDK 5 on the Mac
> is
> > that instead of having an rt.jar they have classes.jar and ui.jar so you
> > can't use the --with-openjdk-home so you must use
> >
> --with-libgcj-jar=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar
> > but unfortunately I had a typo in the path. I have been reading your
> posts
> > but much is new and I certainly don't understand it all.
> >
>
> --with-openjdk-home wouldn't be an option anyway, it's --with-gcj-home.
> There are basically three possible setups:
>
> * default build: does a bootstrap build (build with gcj+ecj first,
> then the built IcedTea), --with-gcj-home can be used to point to the
> JDK tree.
> * openjdk build: --with-openjdk turns this on, --with-openjdk-home
> points to the JDK tree. The build JDK is expected to be a copy of raw
> OpenJDK. Not sure how well tested this is anymore.
> * icedtea build --with-icedtea turns this on, --with-icedtea-home
> points to the JDK tree. The build JDK is expected to be an earlier
> IcedTea. It essentially does the second stage of the default build,
> and fails even with the oldest versions of IcedTea (those based on 7)
> as it expects some plugin classes to be in the existing IcedTea build.
>
> --with-libgcj-jar was dropped because it doesn't really fit in
> coherently. It was only being used by the default build, but yet
> there was no equivalent for the openjdk or icedtea builds. It doesn't
> get around the need for a correct JDK tree as libjvm.so will be
> expected to be present in jre/lib/${arch}/(client|server). IcedTea
> seems to have adopted a hybrid approach of assuming and not assuming a
> JDK tree for the GCJ build and it simplifies things if we settle on a
> single approach.
>
> The JDK tree structure has become a defacto standard and is relied
> upon by quite a few Java applications, especially Apache ones. I'm
> surprised that the JDK you have doesn't follow this. We had a lot of
> problems with GNU Classpath when running applications that expected
> this structure of a tools.jar with the compiler, an rt.jar with the
> class library, etc. to the point that gcj-java-compat was created to
> provide a JDK-like tree for GCJ installs. In turn, the IcedTea build
> expects this to be present as it is on current versions of Fedora,
> Debian, Ubuntu, etc. with the correct packages installed.
>
> It's actually easier to create such a tree than pass in numerous
> options to specify every little file. Just create a tree with a
> jre/lib/rt.jar pointing to your class library and a
> jre/lib/${arch}/(client|server)/libjvm.so pointing to your libjvm.so
> e.g.
>
> $ find /usr/lib/gcj-jdk-4.3
> /usr/lib/gcj-jdk-4.3
> /usr/lib/gcj-jdk-4.3/bin
> /usr/lib/gcj-jdk-4.3/bin/jar
> /usr/lib/gcj-jdk-4.3/bin/java
> /usr/lib/gcj-jdk-4.3/bin/rmic
> /usr/lib/gcj-jdk-4.3/bin/keytool
> /usr/lib/gcj-jdk-4.3/bin/javac
> /usr/lib/gcj-jdk-4.3/bin/javah
> /usr/lib/gcj-jdk-4.3/bin/javap
> /usr/lib/gcj-jdk-4.3/bin/appletviewer
> /usr/lib/gcj-jdk-4.3/bin/jarsigner
> /usr/lib/gcj-jdk-4.3/bin/javadoc
> /usr/lib/gcj-jdk-4.3/bin/rmiregistry
> /usr/lib/gcj-jdk-4.3/jre
> /usr/lib/gcj-jdk-4.3/jre/bin
> /usr/lib/gcj-jdk-4.3/jre/bin/java
> /usr/lib/gcj-jdk-4.3/jre/bin/keytool
> /usr/lib/gcj-jdk-4.3/jre/bin/rmiregistry
> /usr/lib/gcj-jdk-4.3/jre/lib
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/client
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/client/libjvm.so
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/libjawt.so
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/server
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/server/libjvm.so
> /usr/lib/gcj-jdk-4.3/jre/lib/rt.jar
> /usr/lib/gcj-jdk-4.3/lib
> /usr/lib/gcj-jdk-4.3/lib/tools.jar
> /usr/lib/gcj-jdk-4.3/include
>
> The above is now created by the Gentoo gcj-jdk ebuild after a process
> of trial and error finding what was expected by different Java apps,
> etc. Note that include is a symlink to gcj's include directory with
> jni.h.
Okay, I created the Java/JRE structure as you suggested and I am able to
configure icedtea6. The only thing I really didn't know is that libjvm.so is
libjvm.dylib on the MacOSX platform so I left them like that and will wait
to see the consequences. I used ppc64 as the architecture.
new-host:icedtea6 eric$ ./configure --enable-zero=yes --with-project=bsd
--with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
--with-gcj-home=/Library/Java/Home
--with-xalan2-jar=/opt/local/share/java/xalan.jar
--with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
--with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
--with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect
The --with-project=bsd of course is ignored in icedtea6.
I'm able to call make and it downloads the first piece but I have a md5sum
which doesn't understand the option --check. Don't know if this will be a
problem on other BSD platforms.
hotspot_md5sum="`gawk 'version==$1 {print $3}' version=14.0b08 \
/Users/eric/java/icedtea6/hotspot.map`" ; \
if ! echo "${hotspot_md5sum} hotspot.tar.gz" \
| /sw/bin/md5sum --check ; \
then \
if [ hotspot.tar.gz ] ; \
then \
mv hotspot.tar.gz hotspot.tar.gz.old ; \
fi ; \
changeset="`gawk 'version==$1 {print $2}' version=14.0b08 \
/Users/eric/java/icedtea6/hotspot.map`" ; \
/usr/local/bin/wget
http://hg.openjdk.java.net/jdk7/hotspot/hotspot/archive/${changeset}.tar.gz-O
hotspot.tar.gz ; \
fi
/sw/bin/md5sum: illegal option -- -
usage: md5sum [-bv] [-c [file]] | [file...]
Generates or checks MD5 Message Digests
-c check message digests (default is generate)
-v verbose, print file names when checking
-b read files in binary mode
>
>
> > Removing the --with-libgcj-jar cuts off the path to what I am attempting
> to
> > do. (icedtea6 no longer works since I updated) If you can use any java 5
> > complier to create IcedTea JDK, the resultant can be used after that. If
> it
> > is possible to keep IcedTea like IcePick "which allows the OpenJDK
> language
> > tools (javac, javadoc, javah, javap, apt) to be built separately using
> any
> > 1.5 compliant Java compiler..." that would be great. Unless there is an
> > alternate way to point to the runtime jar.
> >
>
So I guess now I will have to wait for the removal of the --with-libgcj-jar
option in the icedtea7 code. I tried hg update and received no updates.
> --
> Andrew :-)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090102/b910ff63/attachment.html
More information about the bsd-port-dev
mailing list