Re: [Jamvm-general] Cannot create system class loader (JamVM1.5.0/Classpath0.96.1/MonteVista PPC)
Thanks everyone for your help. The host_os var was not getting set correctly by the configure script, which resulted in the can_build_shared flag to be set to no instead of yes. I forced host_os to linux and the shared libs are getting correctly generated now. Bregitte On Nov 8, 2007 3:05 AM, Vladimir Nikolov [EMAIL PROTECTED] wrote: Hi Bregitte, I don't know I if you have still fixed your problem, but I had the same situation just some weeks ago, as I cross-compiled the gnu-classpath 0.96.1 and the jamvm-1.5.0 to work together on an ARM machine. However, jamvm queries for shared objects (or should I say shared libraries?) in /usr/local/classpath/lib/classpath, as Rob explained, or in your classpath-inst-dir. Though, the crosscompiler generated on my environment static libraries (.a files) and the links to them (.la files). I fixed the problem as following: Static libraries in Linux are just normal ar archives, containing the compiled objects, which you can extract via ar -x. When you have extracted those objects belonging to the appropiate .a file you can build simply a shared lib (.so) with them using GCC. For example for libjavaio in /usr/local/classpath/lib/classpath: ar -x libjavaio.a gcc -shared http://www.adp-gmbh.ch/cpp/gcc/gcc_options.html#opt_shared -Wl http://www.adp-gmbh.ch/cpp/gcc/gcc_options.html#opt_cap_w_l,-soname,libjavaio.so -o http://www.adp-gmbh.ch/cpp/gcc/gcc_options.html#opt_o libjavaio.so *.o rm *.o Of course the GCC should be your cross-compiler! That functioned for me. Cheers, Vladimir Bregitte Pracht 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. 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. 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. 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
Re: Cannot create system class loader (JamVM1.5.0/Classpath0.96.1/MonteVista PPC)
Hi, On 11/6/07, Bregitte Pracht [EMAIL PROTECTED] wrote: I posted this to jamvm-general, but thought I'd post this here as well, in case it is a classpath problem... I'd appreciate any help on the issue. I've just replied on jamvm-general. It doesn't sound like a jamvm issue (Classpath's .so's are missing). It sounds like a simple installation issue. Rob. Thanks! -b. -
Cannot create system class loader (JamVM1.5.0/Classpath0.96.1/MonteVista PPC)
I posted this to jamvm-general, but thought I'd post this here as well, in case it is a classpath problem... I'd appreciate any help on the issue. Thanks! -b. - 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. 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. 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. Does anyone have any idea what I may be doing wrong? Thanks! -b.
Re: [Jamvm-general] Cannot create system class loader (JamVM1.5.0/Classpath0.96.1/MonteVista PPC)
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
