Re: feedback on --enable-java-home

[Andrew Haley <aph at redhat dot 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.