gcc-3.2 patches - update - j2sdk notes

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

Sorry...forgot the patch...

On Saturday 24 August 2002 07:58 am, you wrote:
> 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.
> Basically:
> 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
>    done
> 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?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: java_vm.sh
Type: application/x-shellscript
Size: 1379 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-dev/attachments/20020824/466ebe66/attachment.bin>

More information about the blfs-dev mailing list