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