gcc-3.2 patches - update - j2sdk notes

Kelledin kelledin+LFS at skarpsey.dyndns.org
Sat Aug 24 05:58:05 PDT 2002

On Saturday 24 August 2002 06:55 am, Richard wrote:
> 	Short and to the point: count me in :o) as I am about start
> building a new gcc-3.2-based LFS partition (all the way to
> KDE) in a matter of hours. Be sure to hear from me if anything
> crops up. My QA rests on j2sdk: this one has been a hard nut
> to crack (as it exposes gcc shortcomings)...

Well, not necessarily gcc shortcomings, but rather ld.so run-time 
linker shortcomings.  Here's what I'd suggest:

First follow 
http://hints.linuxfromscratch.org/hints/javafromscratch.txt .  
It mentions a patch or two to make the code fully C++ compliant 
and fix a link problem or two.

There's more you need to do to j2sdk though--partly to work 
around that ld.so run-time linker shortcoming I mentioned, and 
make it work with Mozilla.  I've sent the changes to Tushar (the 
javafromscratch hint maintainer), but I'm pretty sure he won't 
commit them for a while, as he's on vacation (lucky bastard), 
and he's probably rather tired of me crapping on his vacation 
with a j2sdk-related mail flood. ;)  So I'll post it here to 
save you some potential headache.


1) Do everything in the javafromscratch hint up to symlinking 
   $JAVA_HOME/plugin/ns610/libjavaplugin_oji140.so in your
   mozilla plugin directory.  Note well, SYMLINK the plugin.  DO
   NOT copy it over, move it over, or hard-link it.  If you ask,
   I could make it clear to you why you must do this, but it's a
   large, slimy, smelly can of worms.

2) ln -sf ../jre/bin/java_vm $JAVA_HOME/bin/java_vm &&
   cd $JAVA_HOME/lib &&
   for FNAME in ../jre/lib; do
      ln -s $FNAME

3) mv $JAVA_HOME/jre/bin/java_vm $JAVA_HOME/jre/bin/java_vm.bin

4) Copy the attached script over to $JAVA_HOME/jre/bin/java_vm 
   and give it permissions 0755.  This is a wrapper script that
   works around a few shortcomings--primarily the ld.so run-time
   linker shortcoming I mentioned above.

5) You should probably edit the java_vm wrapper script; in 
   particular, it makes one hard-and-fast assumption about 
   $JAVA_HOME at very beginning that you might want to change.  
   Everything else in the script _should_ be kosher.

To test the java installation, try the following in XFree86:

1) Give root permission to access the display (via "xhost 
   localhost") and make sure root's DISPLAY environment variable 
   is set to "localhost:0.0".  root should now be able to run
   xterm successfully.

2) Add $JAVA_HOME/bin and $JAVA_HOME/jre/bin to your PATH.

3) As root, run "java_vm -t".  This should spew out a lot of 
   trace messages, ending with "Child: Plugin class started",
   and you may notice it briefly initializing a window (that 
   window goes away VERY fast, so you may miss it).  From
   what I can tell, it should then exit with return code 6
   ("echo $?" to get the return code).

4) If that works, and you have mozilla installed, run "mozilla 
   http://www.bodo.com/javame.htm ".  Mozilla should pop up and
   display a Java test page with a text-sine-wave applet running.

If all this works, you probably have a working Java installation.

"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list