Hi Larry,
On 10/8/07, Larry Suto <[EMAIL PROTECTED]> wrote:
> Thanks for the info....I am compiling with the defaults and when I copy the
> files over to the target I am placing them in a linux filesystem at the
> default locations and then I nfs mount it to the target and the I chroot .
> in the mounted directory so it seems like I have the files in the default
> location
>
> I tried the override and it seems like it went further:
>
> ./jamvm
> -Xbootclasspath:/usr/local/jamvm/share/jamvm:/usr/local/classp
> ath/share/classpath
> -Dgnu.classpath.boot.library.path=/usr/local/classpath/lib/c
> lasspath Test
> Exception occurred while VM initialising.
> java/lang/NoClassDefFoundError: java/lang/Thread
>
No, java.lang.Thread is the first class JamVM attempts to load, so
it's failed almost immediately. It looks like you've specified the
bootclasspath wrong... Have a look in /usr/local/jamvm/share/jamvm
and /usr/local/classpath/share/classpath. The classes should be in
classes.zip and glibj.zip. This needs to be specified (i.e.
-Xbootclasspath:/usr/local/jamvm/share/jamvm/classes.zip:/usr/local/classpath/share/classpath/glibj.zip).
But this is irrelevant. By using chroot the classes should look like
they're in the right place anyway.
My guess would be that JamVM is finding the library correctly, but a
dependency is failing, so the dlopen fails. You'll need to add a
debug printf to discover the cause.
In jamvm/src/os/linux/os.c
change:
void *nativeLibOpen(char *path) {
return dlopen(path, RTLD_LAZY);
}
to
void *nativeLibOpen(char *path) {
void *ret;
printf("******** NATIVE LIB OPEN %s\n", path);
ret = dlopen(path, RTLD_LAZY);
if(ret == NULL)
printf("DLOPEN FAILED %s\n", dlerror());
return ret;
}
Also, when running the test, please add -verbose -verbose:jni this
will indicate whether JamVM is finding the boot classes, and what JNI
methods it's trying to call.
Rob.
> for jamvm I use ./configure
> for classpath I use ./configure --with-jikes --enable-jni --disable-gtk-peer
> --disable-gconf-peer --disable-plugin
>
>
> On 10/8/07, Robert Lougher <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On 10/8/07, Christian Thalinger <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2007-10-08 at 01:42 -0700, Larry Suto wrote:
> > > > Hi I am trying to get classpath .93 compiled for a Marvell ARM5
> > > > processor.....I can compile in the scratchbox crosscompile environment
> > > > without any problems...but if copy the classpath files over to the
> > > > native environmentI get this error from jamvm
> > > >
> > > > sh-2.05b# ./gjar
> > > > Cannot create system class loader
> > > > Exception occured while printing exception
> > > > (java/lang/NoClassDefFoundError)...
> > > > Original exception was java/lang/UnsatisfiedLinkError
> > >
> > > Can you run JamVM with -verbose:jni to see which native method is
> > > failing?
> > >
> > > - twisti
> > >
> >
> > Could you also provide details of how you configured/built JamVM and
> Classpath?
> >
> > In general, there are two common problems people have when
> > cross-compiling JamVM :
> >
> > 1) They configure JamVM/Classpath on the host to install in one place,
> > and then copy the files to somewhere else on the target. This doesn't
> > work, because JamVM builds at compile time default boot class and
> > library paths based on where it was configured to be installed.
> >
> > By default, JamVM is installed in /usr/local/jamvm, and Classpath
> > /usr/local/classpath. You can change the place using --prefix=xxx
> > when running configure. If you also move Classpath, you need to tell
> > JamVM this by using the --with-classpath-install-dir=xxx
> configure
> > option (this should be set to the --prefix value you gave to
> > Classpath's configure).
> >
> > You can also override the defaults at runtime, e.g.
> >
> > jamvm
> -Xbootclasspath:/path/to/JamVMs/classes.zip:/path/to/Classpaths/glibj.zip
> >
> -Dgnu.classpath.boot.library.path=/path/to/Classpaths/lib/dir
> ...
> >
> > 2) Copying Classpath onto a fat/vfat formatted device.
> >
> > When Classpath is built, libtool creates library names with version
> > numbers in them, and creates symbolic links for shorter forms (from
> > memory) :
> >
> > libX.so.0.0.0
> > libX.so.0 -> libX.so.0.0
> > libX.so -> libX.so.0
> >
> > The problem is fat/vfat does not support symbolic links, so the short
> > forms are lost when Classpath is copied onto it.
> >
> > Either:
> >
> > a) For each library in .../classpath/llib/classpath rename
> > libX.so.0.0.0 to libX.so
> >
> > or,
> >
> > b) Use tar and the -h option to follow the sybolic links. However,
> > this will create 3 versions of each library when you unpack, so you
> > should delete the libX.so.0, and libX.so.0.0 versions.
> >
> >
> > Hope this helps,
> >
> > Rob.
> >
>
>
