Power PC Build

[Andrew John Hughes]

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.

> 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.
>


-- 
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