Classpath 0.96: Update
Hi everyone, Current regressions are as follows: +FAIL: java.awt.TextArea.ScrollbarPaintTest +FAIL: java.awt.ScrollPane.ScrollbarPaintTest +FAIL: java.awt.Scrollbar.ScrollbarPaintTest +FAIL: java.awt.Component.keyPressTest +FAIL: javax.net.ssl.SSLEngine.TestHandshake +FAIL: javax.swing.JTree.getCellRenderer Can someone who knows these classes please take a look? Cheers, -- Andrew :)
Problems bulding classpath 0.93 on ARM5
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 I am using --with-jni When I try to compile this classpath natively on the box ...I get this error : make[3]: Entering directory `/classpath-0.93/native/jni' cd ../.. && /bin/sh ./scripts/check_jni_methods.sh Found a problem with the JNI methods declared and implemented. (-) missing in implementation, (+) missing in header files -Java_java_lang_VMSystem_arraycopy -Java_java_lang_VMSystem_identityHashCode make[3]: *** [all-local] Error 1 make[3]: Leaving directory `/classpath-0.93/native/jni' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/classpath-0.93/native/jni' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/classpath-0.93/native' make: *** [all-recursive] Error 1 Any info would be appreciated. Thanks, Larry
Re: Problems bulding classpath 0.93 on ARM5
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
Re: Problems bulding classpath 0.93 on ARM5
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.
Re: Problems bulding classpath 0.93 on ARM5
On Mon, 2007-10-08 at 02:07 -0700, Larry Suto wrote: > Hi Thanks, > > This is what I get: > > > sh-2.05b# ./jamvm -verbose:jni Test.class > [Dynamic-linking native method > gnu.classpath.VMStackWalker.getCallingClassLoader > ... internal] > [Dynamic-linking native method java.lang.VMClass.forName ... internal] > [Dynamic-linking native method java.lang.VMClass.getComponentType ... > internal] > [Dynamic-linking native method > java.lang.VMThrowable.fillInStackTrace ... intern > al] > [Dynamic-linking native method > java.lang.VMClassLoader.getBootClassPathSize ... > internal] > [Dynamic-linking native method > java.lang.VMClassLoader.getBootClassPathResource > ... internal] > [Dynamic-linking native method > gnu.classpath.VMSystemProperties.preInit ... inte > rnal] > [Dynamic-linking native method java.lang.VMSystem.arraycopy ... > internal] > [Dynamic-linking native method > gnu.classpath.VMSystemProperties.postInit ... int > ernal] > [Dynamic-linking native method java.lang.VMObject.clone ... internal] > [Dynamic-linking native method java.lang.VMRuntime.mapLibraryName ... > internal] > [Dynamic-linking native method java.lang.VMRuntime.nativeLoad ... > internal] > Cannot create system class loader > Exception occured while printing exception > (java/lang/NoClassDefFoundError)... > Original exception was java/lang/UnsatisfiedLinkError Looks like your native libraries are in the wrong place, as Robert wrote. - twisti PS: Please also reply to the list.
Re: Problems bulding classpath 0.93 on ARM5
Thanks for the infoI 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. >
Re: Problems bulding classpath 0.93 on ARM5
Hi Larry,
On 10/8/07, Larry Suto <[EMAIL PROTECTED]> wrote:
> Thanks for the infoI 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.
> >
>
>
Classpath 0.96 Imminent
Hi everyone, Dalibor suggested it would be a good idea to set everyone a firm deadline for the release, so here we go. * If you want your patch in the release, please commit it by: Wednesday 09:00 UTC. My plan after that is to: * Create a release branch (Mark, I know we discussed this earlier but I feel happier knowing the ground under my feet is not going to move...) * Do a regression check and smoke tests (Eclipse, JEdit, help with other apps welcome) * Assuming things look okay, we'll roll this into a release I've flagged a few patches today that JikesRVM is currently patching the build with. I'd be grateful if someone could look these over today or tomorrow. Or, at least scream if you don't want them committed. I'm going to spend the rest of this evening and tomorrow dredging through the bug database and patches list further, and running some smoke tests. Hopefully we can have a release by Wednesday evening if all is well. Anyone want to suggest a suitable name? ;) Cheers, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net pgpMUojZNmYFG.pgp Description: PGP signature
Re: Classpath 0.96 Imminent
On 10/8/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > Anyone want to suggest a suitable name? ;) "Staying Alive"? Stuart. -- http://sab39.netreach.com/
Re: Classpath 0.96 Imminent
On Monday 08 October 2007 20:26, Stuart Ballard wrote: > On 10/8/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > > Anyone want to suggest a suitable name? ;) > > "Staying Alive"? > > Stuart. That does seem appropriate :D How are the JAPI runs made at the moment? It would be nice if there were IcedTea ones. I'd also like a run against JikesRVM, if only a one off; there are some mismatches in the VM classes at present. Thanks, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net pgpjg77nrwr1Q.pgp Description: PGP signature
Re: Classpath 0.96 Imminent
On 10/8/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > That does seem appropriate :D After I posted that I realized that I could have made a Firefly reference and suggested "Too pretty to die"... I don't know if any Classpath hackers are browncoats though. > How are the JAPI runs made at the moment? It would be nice if there were > IcedTea ones. I'd also like a run against JikesRVM, if only a one off; there > are some mismatches in the VM classes at present. I'm afraid I've been unforgivably lax in the Japi department lately; the runs have been broken for a few weeks (since I blogged about it) and I've never gotten around to figuring out why or fixing it. I apologize. I don't want to make a commitment to fixing them within a particular timeframe that I can't keep, though. I'll try to get to it this week sometime, but I can't promise. Are there nightly builds of IcedTea somewhere downloadable in binary form? If so I'd be thrilled to be able to include those in the Japi runs. Stuart. -- http://sab39.netreach.com/
Re: Classpath 0.96 Imminent
Stuart Ballard wrote: On 10/8/07, Andrew John Hughes <[EMAIL PROTECTED]> wrote: Anyone want to suggest a suitable name? ;) "Staying Alive"? I like it. Most excellent! David Daney
Re: Classpath 0.96 Imminent
Hi Andrew, On Mon, 2007-10-08 at 20:11 +0100, Andrew John Hughes wrote: > * Create a release branch (Mark, I know we discussed this earlier but I feel > happier knowing the ground under my feet is not going to move...) Please do. I was just commenting on that I didn't feel the overhead was really necessary since it does mean some double applying of patches to branch and trunk. But if you feel better with a branch then please go for it. Thanks for picking this up! Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Problems bulding classpath 0.93 on ARM5
Thanks,
I added the code and compiles on scratchbox...in that environement I get :
*** NATIVE LIB OPEN /usr/local/classpath/lib/classpath/libjavanio.so
The verbose output is attaches as txt. When I copy this over to the native
platform I now get cannot open binary file...I am verifiying that the code
changes you asked are doing this.
On 10/8/07, Robert Lougher <[EMAIL PROTECTED]> wrote:
>
> Hi Larry,
>
> On 10/8/07, Larry Suto <[EMAIL PROTECTED]> wrote:
> > Thanks for the infoI 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
