Re: feedback on --enable-java-home

[Andrew John Hughes <gnu_andrew at member dot fsf dot org>]

2009/2/13 Andrew Haley <aph@redhat.com>:
> Andrew John Hughes wrote:
>> 2008/11/1 Andrew Haley <aph@redhat.com>:
>>> Andrew John Hughes wrote:
>>>> 2008/10/31 Andrew Haley <aph@redhat.com>:
>>>>> Matthias Klose wrote:
>>>>>
>>>>>> Âb) The symlinks for the header files are wrong, when installed with
>>>>>> Â Â DESTDIR set.
>>>>>>
>>>>>> Âh) Why are the additional symlinks to the rt.jar required?
>>>>>>
>>>>>> Âi) The versioned jar links point to the bin directory, not to the
>>>>>> Â Â lib directory.
>>>>>>
>>>>>> Âj) The versioned jar links are created in the "toplevel" dir, not
>>>>>> Â Â in the lib directory.
>>>>> All fixed.
>
>>>> Just built and installed trunk with:
>>>>
>>>> $GCC_HOME/configure --prefix=$GCC_INSTALL --disable-multilib
>>>> --enable-languages=c,c++,java \
>>>> Â Â --enable-java-awt=gtk,xlib,qt --enable-gconf-peer
>>>> --enable-gstreamer-peer \
>>>> Â Â --enable-java-maintainer-mode --with-java-home=$GCC_INSTALL
>>>> --enable-java-home \
>>>> Â Â --with-jvm-root-dir=$GCC_INSTALL/jdk
>>>> --with-jvm-jar-dir=$GCC_INSTALL/jvm-exports
>>>>
>>>> There still seem to be some issues with the result:
>>>>
>>>> * I'm not sure of the point of specifying --with-java-home. ÂI would
>>>> have assumed that would give the root dir but this is done by
>>>> --with-jvm-root-dir. ÂWhat use case am I missing?
>>> I didn't change this.
>>>
>>>> * --with-jvm-root-dir does not set the root dir, but instead is a
>>>> directory in which a 'java-1.5.0-gcj-1.5.0.0' directory is created.
>>>> Can jvm root dir not be used directly so the user gets full choice
>>>> over what the directory is called? ÂThis naming is Fedora specific.
>>> I can see no reason why not.
>
> I don't intend to do anything about this. ÂIf someone else wants to,
> feel free.
>
>>>> * There is still a broken src.zip symlink:
>>>> -- src.zip -> ../../share/java/src-4.4.0.zip
>>> I didn't change this.
>
> Or this. ÂThere's no way that gcc should install a bunch of .java files into
> src.zip in the install tree. ÂIt's just not the gcc way.
>
>>>> * There is still a broken javac symlink, though it does make some
>>>> sense if ecj will be installed in $prefix/bin later. ÂGiven gcj has
>>>> ecj.jar and creates ecj1, could it not create $prefix/bin/ecj?
>>> Possibly, yes. ÂThe problem is that on distros $prefix/bin/ecj is
>>> owned by Eclipse's ecj package, so it would conflict. ÂI can't see
>>> any purpose to creating ecj in the jvm root dir. ÂIt would
>>> be worth fixing the javac symlink, though, to point to a working
>>> javac.
>
> I wonder if we should simply not generate the javac symlink. ÂWe don't
> have a javac, after all.
>
>>>> * In jre/lib/security, we have a broken symlink: java.security ->
>>>> ../../../../../lib/security/classpath.security. ÂThis is in lib64
>>>> here.
>>> OK, this needs fixing.
>
> I'll do this. ÂI take it, then, that classpath.security should always
> be in $LIBDIR/security/classpath.security. ÂIs that right?
>
> Andrew.
>

The attached patch fixes the following issues:

* Removes the dangling javac and ecj symlinks
* Removes the hardcoded java-1.5.0-gcj-1.5.0 prefix
* Maps x86_64 to amd64 as used by OpenJDK.

Prior to the latter fix, CPU was empty on my build, resulting in
client and server directories being added to jre/lib rather than
jre/lib/${arch}.  I don't know if this is the case on other
architectures; x86 builds are mapped to i386 explicitly, other archs
should use ${host_cpu} but if this worked, I should have got an
(incorrect) x86_64 directory not nothing.  Is this a known issue with
the version of autotools used by gcj?

With this patch, my JDK tree now looks like this:

/home/andrew/build/gcj/jdk/
/home/andrew/build/gcj/jdk/bin
/home/andrew/build/gcj/jdk/bin/jar
/home/andrew/build/gcj/jdk/bin/java
/home/andrew/build/gcj/jdk/bin/orbd
/home/andrew/build/gcj/jdk/bin/rmic
/home/andrew/build/gcj/jdk/bin/rmid
/home/andrew/build/gcj/jdk/bin/serialver
/home/andrew/build/gcj/jdk/bin/keytool
/home/andrew/build/gcj/jdk/bin/javah
/home/andrew/build/gcj/jdk/bin/native2ascii
/home/andrew/build/gcj/jdk/bin/appletviewer
/home/andrew/build/gcj/jdk/bin/tnameserv
/home/andrew/build/gcj/jdk/bin/jarsigner
/home/andrew/build/gcj/jdk/bin/javadoc
/home/andrew/build/gcj/jdk/bin/rmiregistry
/home/andrew/build/gcj/jdk/jre
/home/andrew/build/gcj/jdk/jre/bin
/home/andrew/build/gcj/jdk/jre/bin/java
/home/andrew/build/gcj/jdk/jre/bin/orbd
/home/andrew/build/gcj/jdk/jre/bin/rmid
/home/andrew/build/gcj/jdk/jre/bin/keytool
/home/andrew/build/gcj/jdk/jre/bin/tnameserv
/home/andrew/build/gcj/jdk/jre/bin/rmiregistry
/home/andrew/build/gcj/jdk/jre/lib
/home/andrew/build/gcj/jdk/jre/lib/amd64
/home/andrew/build/gcj/jdk/jre/lib/amd64/client
/home/andrew/build/gcj/jdk/jre/lib/amd64/client/libjvm.so
/home/andrew/build/gcj/jdk/jre/lib/amd64/libjawt.so
/home/andrew/build/gcj/jdk/jre/lib/amd64/server
/home/andrew/build/gcj/jdk/jre/lib/amd64/server/libjvm.so
/home/andrew/build/gcj/jdk/jre/lib/security
/home/andrew/build/gcj/jdk/jre/lib/security/java.security
/home/andrew/build/gcj/jdk/jre/lib/rt.jar
/home/andrew/build/gcj/jdk/lib
/home/andrew/build/gcj/jdk/lib/tools.jar
/home/andrew/build/gcj/jdk/include
/home/andrew/build/gcj/jdk/include/jni.h
/home/andrew/build/gcj/jdk/include/linux
/home/andrew/build/gcj/jdk/include/linux/jawt_md.h
/home/andrew/build/gcj/jdk/include/linux/jni_md.h
/home/andrew/build/gcj/jdk/include/jawt.h

which looks right to me, compared with the jdk/java-1.5.0-gcj-1.5.0.0
hierarchy currently produced by trunk.

ChangeLog:

2009-03-03  Andrew John Hughes  <ahughes@redhat.com>

	* Makefile.am:
	Remove dangling src.zip and javac symlinks.
	* Makefile.in,
	* configure: Regenerated.
	* configure.ac: Drop hard-coded prefix,
	thus removing sdk_dir and making jre_dir="jre".
	Map x86_64 to amd64 as used by OpenJDK.
	* gcj/Makefile.in,
	* include/Makefile.in,
	* testsuite/Makefile.in: Regenerated.


Ok for trunk?
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

Attachment: java_home-01.diff
Description: Text document