Hi Bregitte, On 11/6/07, Bregitte Pracht <[EMAIL PROTECTED]> wrote: > Hi Rob, > > Thanks for the response. My system is not a fat/vfat filesystem; symbolic > links are fully supported and present for other applications. > > I have attached the complete build output for classpath. It's a gzip file. >
OK, I've had a quick look. It looks like you're doing a staging install (i.e. where you install it in a different place to where it finally will be)? The interesting lines are: libtool: install: warning: remember to run `libtool --finish /usr/local/classpath/lib/classpath' >From a little googling it appears that libtool can have problems with this, as paths are hard-coded : http://www.mail-archive.com/[EMAIL PROTECTED]/msg09218.html I suggest either trying the suggestions in the mail, or installing in place (i.e. make install, and not make install DESTDIR=xxx) and then removing afterwards. Problem is, this will require root access to install in /usr/local on the build machine. Hope this helps, Rob. > Thank you for looking into this! > > Regards, > Bregitte > > > On 11/6/07, Robert Lougher <[EMAIL PROTECTED] > wrote: > > Hi Bregitte, > > > > On 11/6/07, Bregitte Pracht <[EMAIL PROTECTED]> wrote: > > > I have cross-compiled JamVM1.5.0 and Gnu Classpath 0.96.1 for the > HardHat > > > PowerPC > > > platform (MonteVista). > > > > > > I used these configure options for classpath: --enable-jni, > > > --disable-gtk-peer, --disable-gconf-peer, > > > --disable-plugin, --disable-Werror, --with-javac. The --with-javac > options > > > is set to point to Sun's > > > JDK1.6/2 javac binary. Of course --host and --build are set as > appropriate > > > for cross-compilation. > > > > > > For jamvm I used the --host and --build configure options as appropriate > for > > > cross-compilation. I also > > > used the --with-classpath-install-dir option to point to the classpath > > > installation. > > > > > > > Those options look OK to me... > > > > > When I try to test this out with a simple hello-world test program and I > get > > > the following error: > > > > > > Cannot create system class loader > > > Exception occurred while printing exception > > > (java/lang/NoClassDefFoundError) > > > Original exception was java/lang/UnsatisfiedLinkError > > > > > > I searched thejamvm-general email archives. In there was a > > > posting that is somewhat similar. > > > The resolution was to enable-jni. I have it enabled. Looking at my > > > /usr/local/classpath/lib/classpath directory, I don't > have > > > any so files, but I have la files. > > > > > > > Yes, this is the problem. The .so files contain the code for JNI > > native methods which Classpath loads when it initialises, and they're > > not there (so JamVM can't find them). > > > > > I assume the problem is that so files need to be created, but I am not > sure > > > why they are not > > > being built nor what I should do to get them to build. > > > > > > > Are you using a fat/vfat filesystem? Copying Classpath onto a > > fat/vfat filesystem doesn't work because it uses symbolic links which > > aren't supported by fat/vfat. Please see problem (2) from this email > > for solutions : > > > > > http://www.nabble.com/Fwd%3A-Problems-bulding-classpath-0.93-on-ARM5-tf4588154.html#a13096515 > > > > If you're not using vfat/fat, send the make and make install output > > from classpath to me and I'll see if I can work out what's happening. > > > > Rob. > > > > > Does anyone have any idea what I may be doing wrong? > > > > > > Thanks! > > > -b. > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > Jamvm-general mailing list > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jamvm-general > > > > > > > > > > >
