Re: feedback on --enable-java-home

Matthias Klose wrote:
> 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.

Ah, I think I see what you're saying.

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

In my installation it assumes that ecj will be installed in install/bin/,
the same directory as gcj.  Do we need to add more configury?  If anyone
doesn't like it, just let 'em create their own 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.
> 
> it would create a dangling symlink if gjdoc is not built.

OK.

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

Yes, that's right.  So that's OK then.

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

It should be like this:

/usr/lib/jvm-exports/java-1.6.0-openjdk-1.6.0.0.x86_64:
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 jaas-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 jaas-1.6.0.jar -> jaas-1.6.0.0.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 jaas.jar -> jaas-1.6.0.0.jar
lrwxrwxrwx 1 root root 59 2008-10-23 10:25 jce-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/jce.jar
lrwxrwxrwx 1 root root 15 2008-10-23 10:25 jce-1.6.0.jar -> jce-1.6.0.0.jar
lrwxrwxrwx 1 root root 15 2008-10-23 10:25 jce.jar -> jce-1.6.0.0.jar
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 jdbc-stdext-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 23 2008-10-23 10:25 jdbc-stdext-1.6.0.jar -> jdbc-stdext-1.6.0.0.jar
lrwxrwxrwx 1 root root 23 2008-10-23 10:25 jdbc-stdext-3.0.jar -> jdbc-stdext-1.6.0.0.jar
lrwxrwxrwx 1 root root 23 2008-10-23 10:25 jdbc-stdext.jar -> jdbc-stdext-1.6.0.0.jar
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 jndi-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 jndi-1.6.0.jar -> jndi-1.6.0.0.jar
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 jndi-cos-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 20 2008-10-23 10:25 jndi-cos-1.6.0.jar -> jndi-cos-1.6.0.0.jar
lrwxrwxrwx 1 root root 20 2008-10-23 10:25 jndi-cos.jar -> jndi-cos-1.6.0.0.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 jndi.jar -> jndi-1.6.0.0.jar
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 jndi-ldap-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 21 2008-10-23 10:25 jndi-ldap-1.6.0.jar -> jndi-ldap-1.6.0.0.jar
lrwxrwxrwx 1 root root 21 2008-10-23 10:25 jndi-ldap.jar -> jndi-ldap-1.6.0.0.jar
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 jndi-rmi-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 20 2008-10-23 10:25 jndi-rmi-1.6.0.jar -> jndi-rmi-1.6.0.0.jar
lrwxrwxrwx 1 root root 20 2008-10-23 10:25 jndi-rmi.jar -> jndi-rmi-1.6.0.0.jar
lrwxrwxrwx 1 root root 60 2008-10-23 10:25 jsse-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/jsse.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 jsse-1.6.0.jar -> jsse-1.6.0.0.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 jsse.jar -> jsse-1.6.0.0.jar
lrwxrwxrwx 1 root root 58 2008-10-23 10:25 sasl-1.6.0.0.jar -> ../../jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 sasl-1.6.0.jar -> sasl-1.6.0.0.jar
lrwxrwxrwx 1 root root 16 2008-10-23 10:25 sasl.jar -> sasl-1.6.0.0.jar

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

Andrew.