Re: feedback on --enable-java-home

[Matthias Klose <doko at ubuntu dot com>]

Andrew Haley schrieb:
> 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.

DESTDIR is a temporary installation location; the symlink should point to the
correct location, which you did configure with --prefix. Once you remove your
temporary location and move the files into the final destinations, the symlink
is dangling.

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

sorry, this is the javac symlink pointing to ecj and assuming the location of ecj.

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

it would create a dangling symlink if gjdoc is not built.

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

they do work. but I see that other symlinks created in the gcc lib dir do have
the same form.

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

could you give me a pointer what should be found in jvm-exports?

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

Proposing java-1.5.0-gcj-1.5.0.0/jre/man/man1 and
java-1.5.0-gcj-1.5.0.0/man/man1, but I see this is not done in java-gcj-compat.

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

I did see that some apps which were using openjdk and couldn't find the file did
give an error. iirc mjw did track this down to direct access to this file.

  Matthias