I'm trying to package up a java package for octave that links to
libjava.so. Problem I'm having is that when octave tries to load the
module at run time it can't find libjava.so. How should this be remedied?
Thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
Hi,
Now that we have people using Eclipse on IcedTea, we have people
starting to hit memory limits. I don't understand the situation very
well, but here are some links to Eclipse bug reports, etc.:
http://www.eclipsezone.com/eclipse/forums/t101303.rhtmlhttp://wiki.eclipse.org/FAQ_How_do_I_increase_the_permgen_size_available_to…https://bugs.eclipse.org/bugs/show_bug.cgi?id=195897
- the Eclipse launcher (largely written in C) can tell if it's running
on a Sun VM on Windows -- it looks like it reads .dll headers -- but
not on Linux
I spoke briefly with Andrew Niefer and a few other people on IRC and
here are a few options for fixing the launcher to work with the -XX
options in both the Sun VM and non-Sun VM cases:
1. try starting the VM using the invocation api (using libjvm.so) with
the PermSize argument and see if it fails - if it does, launch
without the option. This may add some startup delay to VMs that
don't support this option. This was suggested in the eclipse.org
bug I link to above.
2. look for a jre/LICENSE text file and seeing if it starts with "Sun
Microsystems". Andrew Niefer suggested this option.
Can anyone think of anything better? Note that I don't want to add a
shell wrapper around the binary Eclipse launcher unless we absolutely
have to.
The Eclipse launcher code can be seen in CVS here:
:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
Module: org.eclipse.equinox.executable
Branch: R3_3_maintenance (or HEAD if you like)
Specifically, library/win32/eclipseWin.c in the isSunVM() function.
library/eclipseNix.c has an isSunVM() that just returns 0.
Andrew
Trying Blue Marine (http://bluemarine.tidalwave.it) which
certainly didn't work with GIJ, so I hoped it actually could work
with java-1.7.0-icedtea-1.7.0.0-0.14.b18.snapshot.fc8 from
Rawhide. Unfortunately, although installation went smoothly, this
is the output of attempt to run the program itself after it was
installed in $HOME/.blueMarine directory (long lines broken in
indicated places to make slrn happy):
[matej@viklef .blueMarine]$ java -version
java version "1.7.0"
IcedTea Runtime Environment (build \
1.7.0-kojibuilder_28_aug_2007_13_29-b00)
IcedTea Client VM (build 1.7.0-kojibuilder_28_aug_2007_13_29-b00, \
mixed mode)
[matej@viklef .blueMarine]$ cat blueMarine.sh
#!/bin/sh
# $Id: blueMarine.sh 2378 2007-07-23 10:16:45Z fabriziogiudici $
export BLUEMARINE_HOME=/home/matej/.blueMarine
export MEMORY=-Xmx512M
export VERSION=0.9.RC1.2533
export AWT_TOOLKIT=MToolkit
export CLASSPATH=$BLUEMARINE_HOME/bluemarine/platform7/lib/boot.jar\
:$BLUEMARINE_HOME/bluemarine/platform7/lib/boot2.jar\
:$BLUEMARINE_HOME/bluemarine/platform7/lib/org-openide-modules.jar\
:$BLUEMARINE_HOME/bluemarine/platform7/lib/org-openide-util.jar\
:$BLUEMARINE_HOME/bluemarine/platform7/modules/ext/updater.jar
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/bin/java -ea $MEMORY\
-Dnetbeans.osenv.nullsep=false\
-Dnetbeans.home=$BLUEMARINE_HOME/bluemarine/platform7\
-Dnetbeans.logger.console=false -Dit.tidalwave.openide.app=$0\
-Dit.tidalwave.bluemarine.showtabs=false\
-Dit.tidalwave.bluemarine.version=$VERSION -cp $CLASSPATH\
it.tidalwave.netbeans.boot.Main
[matej@viklef .blueMarine]$ ./blueMarine.sh
Exception in thread "main" java.lang.UnsatisfiedLinkError: \
Can't load library:\
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/i386/motif21/libmawt.so
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1668)
at java.lang.Runtime.load0(Runtime.java:788)
at java.lang.System.load(System.java:1042)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1769)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1686)
at java.lang.Runtime.loadLibrary0(Runtime.java:841)
at java.lang.System.loadLibrary(System.java:1067)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:68)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:48)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1626)
at java.awt.Toolkit.<clinit>(Toolkit.java:1648)
at it.tidalwave.netbeans.boot.Main.main(Unknown Source)
[matej@viklef .blueMarine]$
Is it expected (considering the state of the IcedTea
development), or should I file a bug (where?).
Thanks for any reply,
Matěj
----- Forwarded message from Jerry James <loganjerry(a)gmail.com> -----
> From: Jerry James <loganjerry(a)gmail.com>
> To: Andrew Overholt <overholt(a)redhat.com>
> Cc: Development discussions related to Fedora <fedora-devel-list(a)redhat.com>
> Date: Sat, 8 Sep 2007 21:30:02 -0600
> Subject: Re: aot-compile-rpm suggestion
>
> On 9/7/07, Andrew Overholt <overholt(a)redhat.com> wrote:
> > Please file this as a bug so it can be tracked.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=283831
>
> Thanks,
> --
> Jerry James
> http://loganjerry.googlepages.com/
----- End forwarded message -----
I'm thinking of packaging jgoodies-looks and jgoodies-forms for Fedora
-- they're required for the GUI admin tool for the Ice distributed
object middleware that I'm also wanting to package: it's a big package
that's currently under review
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234612). I
already have local packages of jgoodies that I use for building my own
version of Ice, but it's not in Fedora yet so I've disable that part
of the build for now in the package under review.
Is there anything I should be aware of when packaging jgoodies, or
should I just go for it. :)
Thanks,
MEF
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
Hi list,
I have a problem to build a Eclipse plugin package[1] in rawhide, that
seems to be a bug in the last RPM package, I will fill a bug about this
today. At first view, all Java package that include classes outside a
jar file can have the same troubles (I should test this today too).
With the coming of AcedTea as default JRE for F8 the debuginfo package
can be useful only for 0,1% of our users base, that amount of people is
probably less than that because the user must work on a ppc arch using
eclipse-rse (the package that give problem) and must will to debug it.
So, what do you think about adding %define debug_package %{nil} on the
top of the specfile while this bug is not solved in the RPM package.
[1]
https://www.redhat.com/archives/fedora-devel-java-list/2007-August/msg00009…
Thanks,
Alphonse