Re: feedback on --enable-java-home

Andrew Haley <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
Matthias Klose wrote:

> as "promised" ;), some feedback about the integration of the
> java-gcj-compat stuff. please find extracts from a build log at the
> end.
> 
> Configured with
>   --with-java-home=/usr/lib/gcc-snapshot
>   --enable-java-home
>   --with-jvm-root-dir=/usr/lib/gcc-snapshot/jvm
>   --with-jvm-jar-dir=/usr/lib/gcc-snapshot/jvm-exports
> 
>  a) having both --with-java-home and --enable-java-home is at least
>     confusing, plus with the new schema, --enable-java-home does
>     hardcode a part of --with-java-home, without giving the
>     possibility to select the jvm name anymore.
>     Please merge --with-java-home/--enable-java-home and make it
>     possible to give your own name. Where's the value about having to
>     use `java-1.5.0-gcj-1.5.0.0'? is this documented?
> 
>  b) The symlinks for the header files are wrong, when installed with
>     DESTDIR set.

I'm not exactly sure what this means.  I get

/usr/local/lib/gcc-snapshot/jvm/java-1.5.0-gcj-1.5.0.0/include/linux/jni_md.h -->
../../../../../../../../home/aph/gcc/trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/jawt_md.h

which works fine.

>  c) The ecj symlink assumes an installation of ecj in a given
>     location, which apparently is only true for installations into
>     /usr or /usr/local. This should be configurable.

I haven't got an ecj symlink.

>  d) The javadoc symlink is created unconditionally, but gjdoc is not
>     built in all cases.

I'm not sure what good it would do not to create the symlink.

>  e) The src.zip symlink is dangling, the default install never
>     installs the src zip.

Confirmed.  Will fix.

>  f) The symlinks to the .so files should be normalized, at least for
>     multilib builds these look like:
>       libjawt.so -> ../../../../lib/../lib/gcj-4.4.0-10/libjawt.so

They seem to work ... what is the problem?

>  g) No documentation about the new options in gcc/doc/install.texi
> 
>  h) Why are the additional symlinks to the rt.jar required?

I think the idea is to provide the contents of jvm-exports, but it hasn't
worked because of the dangling symlinks.

/usr/local/lib/gcc-snapshot/jvm-exports/java-1.5.0-gcj-1.5.0.0/sasl.jar -->
sasl-1.5.0.0.jar -->
/home/aph/gcc/trunk/install/bin/sasl.jar

This last link is wrong: it should point to

/usr/local/lib/gcc-snapshot/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/sasl.jar -->
rt.jar

which is the real destination.

>  i) The versioned jar links point to the bin directory, not to the
>     lib directory.

Confirmed.  Needs fixing.

>  j) The versioned jar links are created in the "toplevel" dir, not
>     in the lib directory.

Confirmed.  Needs fixing.

>  k) Symlinks to the manual pages would be nice as well.

In the java-home dir?

>  l) Should a cacerts file created by default? At least java-gcj-compat
>     did include a generate-cacerts.pl script.

I'm not certain about this; perhaps not.

Andrew.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.