Thread: [Sablevm-developer] Problems with 1.0.3 - java/lang/UnsatisfiedLinkError
Brought to you by:
egagnon
From: Grzegorz P. <ga...@de...> - 2002-08-20 14:41:07
|
Hi! I updated debian packages to 1.0.3 version and now I am unable to run even HelloWorld.jar. Short output is this: greg@greg:~$ java -jar HelloWorld.jar=20 /usr/bin/sablevm -Y --classpath=3DHelloWorld.jar: HelloWorld java/lang/UnsatisfiedLinkError Longer: greg:/home/greg# java -v -jar ./HelloWorld.jar=20 /usr/bin/sablevm -Y --classpath=3D./HelloWorld.jar: -v HelloWorld [verbose jni: JNI_CreateJavaVM] [verbose gc: allocating initial heap (16777216 bytes)] [verbose class: loading "java/lang/Object"] [verbose class: loading "java/io/Serializable"] [verbose class: loading "java/lang/Cloneable"] [verbose class: creating "[B"] [verbose class: loading "java/lang/Class"] [verbose class: loading "java/lang/StackTraceElement"] [verbose class: loading "java/lang/reflect/Constructor"] [verbose class: loading "java/lang/reflect/AccessibleObject"] [verbose class: loading "java/lang/reflect/Member"] [verbose class: loading "java/lang/reflect/Field"] [verbose class: loading "java/lang/reflect/Method"] [verbose class: loading "java/lang/StringCreator"] [verbose class: loading "java/lang/VirtualMachine"] [verbose class: creating "[Z"] ................. [verbose class: loading "java/util/AbstractMap$BasicMapEntry"] [verbose class: loading "java/util/Map$Entry"] [verbose class: creating "[Ljava/util/Hashtable$HashEntry;"] [verbose class: loading "java/util/StringTokenizer"] [verbose class: loading "java/util/Enumeration"] [verbose class: creating "[Ljava/lang/String;"] [verbose class: loading "java/lang/StringBuffer"] [verbose class: loading "java/lang/VMSecurityManager"] java/lang/UnsatisfiedLinkError [verbose gc: total gc time =3D 0 sec 0 usec] I tried Archie's patch for FreeBSD but it didn't help. it is not a problem with non-existant /usr/lib/sablevm/classes-1.0.3. For now I reverted to 1.0.1. Grzegorz B. Prokopski PS: I decided not to file a bug in BTS, as this: a) can be some packaging/system/my fault problem type b) should be resolved rather quickly (not in next year) c) I am sure I will remember about it ;-) |
From: Etienne M. G. <eti...@uq...> - 2002-08-20 16:49:42
|
Hi Grzegorz, On Tue, Aug 20, 2002 at 04:41:55PM +0200, Grzegorz Prokopski wrote: > I updated debian packages to 1.0.3 version and now I am unable > to run even HelloWorld.jar. >... > it is not a problem with non-existant /usr/lib/sablevm/classes-1.0.3. >... > For now I reverted to 1.0.1. > b) should be resolved rather quickly (not in next year) I uninstalled all sablevm versions from my machine, restartd my shell (to clear the PATH search path), downloaded the three *-1.0.3.tar.gz packages, extracted the "build" script, and ran: $ build /home/egagnon/work # with no trailing "/" ... $ type sablevm /home/egagnon/work/bin/sablevm $ sablevm -Yc HelloWorld.jar HelloWorld Hello World! $ So, you have probably missed one of the installation steps. I suggest you uninstall all previous sablevm versions from your machine, and restart installation from pristine packages. As you probably use an unusual build procedure for building the deb package, please send your scripts so that more eyes look at it. Or, maybe there's a strange system-specific bug in sablevm? I've ran my tests on Debian sid (with jikes frozen to "testing"'s 1.15 version). ------------ About the GTK stuff: I'll look at it when I'm finished. ------------ About the Bug tracking messages: You can subscribe to the sablevm-bugs ML. Keeping separate MLs allows one to chose what to receive or not, in digest format or not. ------------ Have fun! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz P. <gr...@se...> - 2002-08-20 17:20:53
|
W li=B6cie z wto, 20-08-2002, godz. 18:36, Etienne M. Gagnon pisze:=20 > Hi Grzegorz, >=20 > On Tue, Aug 20, 2002 at 04:41:55PM +0200, Grzegorz Prokopski wrote: > > I updated debian packages to 1.0.3 version and now I am unable > > to run even HelloWorld.jar. > >... > > it is not a problem with non-existant /usr/lib/sablevm/classes-1.0.3. > >...=20 > > For now I reverted to 1.0.1. > > b) should be resolved rather quickly (not in next year) >=20 > I uninstalled all sablevm versions from my machine, restartd my shell > (to clear the PATH search path), downloaded the three *-1.0.3.tar.gz > packages, extracted the "build" script, and ran: Ups... that's really strange. > So, you have probably missed one of the installation steps. I suggest > you uninstall all previous sablevm versions from your machine, and > restart installation from pristine packages. hmm... strange, because I don't "just build from source", but I builded debs - the same way as before - for 1.0.1 > As you probably use an unusual build procedure for building the deb > package, please send your scripts so that more eyes look at it. They are (of course) at http://debian.sente.pl/debian - just take the *.diff.gz files - there's everything in them. or take also *.dsc and *.orig.tar.gz files, then dpkg-source -x them. then go into created directories one by one and issue dpkg-buildpackage -rfakeroot it is (almost) the same as: fakeroot ./debian/rules binary (rules is just a Makefile) There must have sth. changed or it's some strange side effect. My "deb update" means patching new source with old debianizing diff, so I didn't change anything really. > Or, maybe there's a strange system-specific bug in sablevm? I've ran > my tests on Debian sid (with jikes frozen to "testing"'s 1.15 > version). I have 1.15-2 jikes installed and "on hold". > About the GTK stuff: I'll look at it when I'm finished. Great! but wait a minute - so... it never worked? were you testing peers in any way? BTW: how's your work going? > About the Bug tracking messages: You can subscribe to the sablevm-bugs I will. GBP |
From: Etienne M. G. <eti...@uq...> - 2002-08-20 18:08:48
|
On Tue, Aug 20, 2002 at 07:21:32PM +0200, Grzegorz Prokopski wrote: > They are (of course) at http://debian.sente.pl/debian - just take the > *.diff.gz files - there's everything in them. > or take also *.dsc and *.orig.tar.gz files, then dpkg-source -x them. > then go into created directories one by one and issue > dpkg-buildpackage -rfakeroot > it is (almost) the same as: > fakeroot ./debian/rules binary > (rules is just a Makefile) I'm sure you do understand I don't have time to learn about debian packaging scripts (and so on) at this point, but I'm sure others will help. :-) > BTW: how's your work going? Progressing. :-) That's all for today! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz P. <gr...@se...> - 2002-08-20 18:24:22
|
W li=B6cie z wto, 20-08-2002, godz. 20:04, Etienne M. Gagnon pisze:=20 > On Tue, Aug 20, 2002 at 07:21:32PM +0200, Grzegorz Prokopski wrote: > > They are (of course) at http://debian.sente.pl/debian - just take the > > *.diff.gz files - there's everything in them. > > or take also *.dsc and *.orig.tar.gz files, then dpkg-source -x them. > > then go into created directories one by one and issue > > dpkg-buildpackage -rfakeroot > > it is (almost) the same as: > > fakeroot ./debian/rules binary > > (rules is just a Makefile) > I'm sure you do understand I don't have time to learn about debian > packaging scripts (and so on) at this point, but I'm sure others will > help. :-) Yes I do - I was only testing you ;-) with hope, that you may already know the "internals" a little bit more. But I think - another irc session (an hour or maybe two) and you'll be ready for it. Seriously - I don't have any other non-potato machine but the one I use. So if anyone could try those 1.0.3 packages - debs and maybe even compile them from sources - I'd be thankful. > > BTW: how's your work going? > Progressing. :-) I hope you finish it soon so that we could work on SableVM (together) a bit more. > That's all for today! Self-discipline is Good Thing :-] Regards GBP |
From: Etienne M. G. <eti...@uq...> - 2002-08-20 18:24:25
|
On Tue, Aug 20, 2002 at 07:21:32PM +0200, Grzegorz Prokopski wrote: > > About the GTK stuff: I'll look at it when I'm finished. > Great! > but wait a minute - so... it never worked? were you testing peers in > any way? Never tested the stuff (upstream Classpath never claimed stuff to be really working, anyway); was out of Ph.D. scope. ;-) Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz P. <gr...@se...> - 2002-08-20 18:49:14
|
W li=B6cie z wto, 20-08-2002, godz. 20:11, Etienne M. Gagnon pisze:=20 > On Tue, Aug 20, 2002 at 07:21:32PM +0200, Grzegorz Prokopski wrote: > > > About the GTK stuff: I'll look at it when I'm finished. > > Great! > > but wait a minute - so... it never worked? were you testing peers in > > any way? >=20 > Never tested the stuff (upstream Classpath never claimed stuff to be > really working, anyway); Really? But... http://people.debian.org/~jewel/kissme/shots/kissme_awt.png in=20 http://mail.gnu.org/pipermail/classpath/2002-July/002444.html seems to prove sth. different. I wanted to see only that. > was out of Ph.D. scope. ;-) Aahh - that's another story Sidethought: but who's scope is that in then? GBP |
From: Mark W. <ma...@kl...> - 2002-08-20 18:56:00
|
Hi, On Tue, 2002-08-20 at 16:41, Grzegorz Prokopski wrote: > I updated debian packages to 1.0.3 version and now I am unable > to run even HelloWorld.jar. > > Short output is this: > [...] Interesting. This is the exact same output I reported in my previous mail <http://www.geocrawler.com/lists/3/SourceForge/4435/0/9343566/>. But that was based on a 1.0.2 system. Seems we are doing the same thing wrong. Which might mean that the powerpc port is further along then I thought. I am going to try to update to the CVS version and try again. Cheers, Mark |
From: Grzegorz P. <ga...@de...> - 2002-08-20 19:10:11
|
W li=B6cie z wto, 20-08-2002, godz. 20:55, Mark Wielaard pisze:=20 > Hi, >=20 > On Tue, 2002-08-20 at 16:41, Grzegorz Prokopski wrote: > > I updated debian packages to 1.0.3 version and now I am unable > > to run even HelloWorld.jar. > >=20 > > Short output is this: > > [...] >=20 > Interesting. This is the exact same output I reported in my previous > mail <http://www.geocrawler.com/lists/3/SourceForge/4435/0/9343566/>. > But that was based on a 1.0.2 system. Yes, I saw the similiarity. > Seems we are doing the same thing wrong. Which might mean that the > powerpc port is further along then I thought. No, why. I'd say it's right there, very near. Just fetch 1.0.1 version and add your PowerPC stuff to it! > I am going to try to update to the CVS version and try again. If it fails - try 1.0.1 and report the result please. Regards GBP |
From: Mark W. <ma...@kl...> - 2002-08-20 21:31:33
Attachments:
sablevm-ppc.patch
hello.out
|
Hi, On Tue, 2002-08-20 at 21:10, Grzegorz Prokopski wrote: > W li=B6cie z wto, 20-08-2002, godz. 20:55, Mark Wielaard pisze:=20 > > I am going to try to update to the CVS version and try again. > If it fails - try 1.0.1 and report the result please. Here are some datapoints. I didn't have time to do extensive testing or debugging to know what is really happening. The reports below are with the sablevm-debug version. I commented out all other flavors in the build-many script. First I updated the CVS version and extracted the sablevm-class-library-1.0.3.tar.gz and sablevm-native-library-1.0.3.tar.gz files in that directory. Patched the files as attached and disabled all other builds except the debug one in the build-many script. Then I did a ./build-many /usr/local/sablevm. This produced the exact same result as reported before. (Note that it is slightly different from the output that you posted but almost the same.) Then I downloaded the 1.0.1 versions: sablevm-1.0.1.tar.gz, sablevm-class-library-1.0.1.tar.gz and sablevm-native-library-1.0.1.tar.gz. Unpacked sablevm-1.0.1.tar.gz, unpacked the other two archives inside the sablevm-1.0.1 directory and replaced the system.h, system.c and jni_system_specific.h files with the patched CVS versions. This produced a binary that got a little bit further as can be seen in the attached output file but gives a java/lang/ExceptionInInitializerError at the end. I hope someone else will get better results. I will probably not have more time to play with this stuff before the weekend. If you have specific things you want me to try out please let me know, but I won't have time to debug this on my own right now. Good night, Mark |
From: Grzegorz P. <gr...@se...> - 2002-08-20 21:52:50
|
W li=B6cie z wto, 20-08-2002, godz. 23:30, Mark Wielaard pisze:=20 > Hi, >=20 > On Tue, 2002-08-20 at 21:10, Grzegorz Prokopski wrote: > > W li=B6cie z wto, 20-08-2002, godz. 20:55, Mark Wielaard pisze:=20 > > > I am going to try to update to the CVS version and try again. > > If it fails - try 1.0.1 and report the result please. > Then I downloaded the 1.0.1 versions: > sablevm-1.0.1.tar.gz, sablevm-class-library-1.0.1.tar.gz and > sablevm-native-library-1.0.1.tar.gz. > Unpacked sablevm-1.0.1.tar.gz, unpacked the other two archives inside > the sablevm-1.0.1 directory and replaced the system.h, system.c and > jni_system_specific.h files with the patched CVS versions. This produced > a binary that got a little bit further as can be seen in the attached > output file but gives a java/lang/ExceptionInInitializerError at the > end. yes, but it got much further it seems. > I hope someone else will get better results. I will probably not have > more time to play with this stuff before the weekend. If you have > specific things you want me to try out please let me know, but I won't > have time to debug this on my own right now. I'd happily try it myself, but unfortunatelly debian machines admins still haven't installed needed packages on the only PowerPC that is freely available to debian developers. [I don't have access to any other PowerPC machine] Idea: The problem may be because the assemmbler part may not be working like it should. If that's the case - please disable assember code for a moment and try that "plain C" version of "test&swap" function (which should never ever be used for real ;) Please pass --enable-debugging-features option to configure, so that we knew you're using most "safe" settings. That's very simple test. I am curious if that makes any difference and if results are always the same for every run. Regards GBP |
From: Mark W. <ma...@kl...> - 2002-08-21 07:25:57
|
Hi, On Tue, 2002-08-20 at 23:53, Grzegorz Prokopski wrote: > Idea: > The problem may be because the assemmbler part may not be working like > it should. If that's the case - please disable assember code for > a moment and try that "plain C" version of "test&swap" function (which > should never ever be used for real ;) I think the assembler is OK. I found a different implementation in libgcj (which is similar but a little but more clever by using xor to use just one register where I use one for tmp and result. And John Leuner said he used the same assembler code for Kissme on powerpc. But I have changed it to just the plain C version of the code for now. > Please pass --enable-debugging-features option to configure, so that > we knew you're using most "safe" settings. I am using the debug build from build-many: ./configure \ --prefix=$LOCATION \ --program-suffix=-debug \ --libdir=$LOCATION/lib/sablevm-debug \ --enable-debugging-features \ --disable-signals-for-exceptions \ --with-gc=copying \ --with-obj-layout=bidirectional \ --with-threading=switch > That's very simple test. > I am curious if that makes any difference and if results are always > the same for every run. Didn't make a difference :{ And it always gives the same result (this is with patched 1.0.1). Cheers, Mark |
From: Etienne M. G. <eti...@uq...> - 2002-08-21 15:20:28
|
On Wed, Aug 21, 2002 at 09:25:08AM +0200, Mark Wielaard wrote: > I think the assembler is OK. I found a different implementation in > libgcj (which is similar but a little but more clever by using xor to > use just one register where I use one for tmp and result. And John > Leuner said he used the same assembler code for Kissme on powerpc. > But I have changed it to just the plain C version of the code for now. You can probably simply revert to the assembly version; the CAS operation is unlikely to cause important side effects in single threaded code, other than causing an IllegalMonitorStateException, if the code does not assing the right value in the object header (*pword). > I am using the debug build from build-many: > > ./configure \ > --prefix=$LOCATION \ > --program-suffix=-debug \ > --libdir=$LOCATION/lib/sablevm-debug \ > --enable-debugging-features \ > --disable-signals-for-exceptions \ > --with-gc=copying \ > --with-obj-layout=bidirectional \ > --with-threading=switch > Good. > Didn't make a difference :{ > And it always gives the same result (this is with patched 1.0.1). The fist thing we want to do it to locate the problem more precisely, using sablevm-debug. So, here are 3 things to do: 1- Run: $ sablevm-debug -p "sablevm.verbose.methods" HelloWorld 2>&1 | tail -1000 > output-methods.txt 2- Run: $ sablevm-debug -p "sablevm.verbose.methods" -p "sablevm.verbose.instructions" HelloWorld 2>&1 | tail -1000 > output-instructions.txt 3- After doihg 1 and 2 above (not before), modify src/libsablevm/interpreter.c, replacing the "#ifdef COMMENT" at the start of the exception handling code by "#ifndef COMMENT", then rebuild and re-install sablevm-debug. 4- Run: $ sablevm-debug HelloWorld 2>&1 > output-exceptions.txt 5- Send a gzipped version of output-*.txt files to this list, for investigation. 6- Revert back the src/libsablevm/interpreter.c change in 3. 7- Rebuild and reinstall sablevm-debug. Be warned that verbose instruction and method trace options are extremely verbose (due to the important number of executd methods and instructions). This is why the "tail" filter is important... Have fun! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Mark W. <ma...@kl...> - 2002-08-21 16:30:55
Attachments:
output-methods.txt.gz
output-instructions.txt.gz
|
Hi, On Wed, 2002-08-21 at 17:11, Etienne M. Gagnon wrote: > The fist thing we want to do it to locate the problem more precisely, > using sablevm-debug. So, here are 3 things to do: > > 1- Run: > > $ sablevm-debug -p "sablevm.verbose.methods" HelloWorld 2>&1 | tail -1000 > output-methods.txt The actual command I ran was: /usr/local/sablevm/bin/sablevm-debug -p "sablevm.verbose.methods=true" \ Hello 2>&1 | tail -5000 > output-methods.txt > 2- Run: > > $ sablevm-debug -p "sablevm.verbose.methods" -p "sablevm.verbose.instructions" HelloWorld 2>&1 | tail -1000 > output-instructions.txt /usr/local/sablevm/bin/sablevm-debug -p "sablevm.verbose.methods=true" \ -p "sablevm.verbose.instructions=true" Hello 2>&1 | tail -10000 > output-instructions.txt I didn't have time to recompile and do the next steps but from the output I suspect the following piece of code in java.io.FileInputStream: public FileInputStream(FileDescriptor fd) throws SecurityException { // Hmmm, no other exception but this one to throw, but if the descriptor // isn't valid, we surely don't have "permission" to read from it. if (!fd.valid()) throw new SecurityException("Invalid FileDescriptor"); Does that make sense to you? Hopefully I can send more data later. (But it might not be till tomorrow). Cheers, Mark |
From: Mark W. <ma...@kl...> - 2002-08-21 22:53:23
|
Hi, On Wed, 2002-08-21 at 18:30, Mark Wielaard wrote: > > I didn't have time to recompile and do the next steps but from the > output I suspect the following piece of code in java.io.FileInputStream: > > public > FileInputStream(FileDescriptor fd) throws SecurityException > { > // Hmmm, no other exception but this one to throw, but if the > descriptor > // isn't valid, we surely don't have "permission" to read from it. > if (!fd.valid()) > throw new SecurityException("Invalid FileDescriptor"); > This seems to be it! After I just commented out that part and recompiled I got: mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello java.lang.ClassNotFoundException: Hello at gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73) at java.lang.ClassLoader.loadClass(ClassLoader.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:259) at java.lang.VirtualMachine.main(VirtualMachine.java:79) I haven't yet figured out why that is but this is progress. And when I copy Hello.class to /usr/local/sablevm/lib/sablevm/classes-1.0.1/ I get: mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello Hello World! Yeah! If "Hello World" is possible everything else should be possible :) I am very happy because this means that there might be some issues on PowerPC but it seems there is not something major wrong. Hopefully I will have some time this weekend to clean up what I have and look at where/why the valid() really fails and why my sablevm cannot find anything besides inside its own bootclasspath directory. Good night, Mark |
From: Grzegorz P. <gr...@se...> - 2002-08-22 00:21:26
|
W li=B6cie z czw, 22-08-2002, godz. 00:52, Mark Wielaard pisze:=20 > I haven't yet figured out why that is but this is progress. And when I > copy Hello.class to /usr/local/sablevm/lib/sablevm/classes-1.0.1/ > I get: > mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello > Hello World! Congrats!!! > Yeah! If "Hello World" is possible everything else should be possible :) Yes, that means we're "almost there" (-: Huh, I think in such way we'll have 12 architectures by the end of this year very easily. I think everybody understand, that this would be major step towards wider acceptance of sablevm as "The Free JVM". > I am very happy because this means that there might be some issues on > PowerPC but it seems there is not something major wrong. Yeah - I was worried a bit about PowerPC being hi-endian, but now you prove my worries to be unnecessary ;-) > Hopefully I will have some time this weekend to clean up what I have and > look at where/why the valid() really fails and why my sablevm cannot > find anything besides inside its own bootclasspath directory. I hope debian admins will finally install those -dev packages I asked for ;-) It takes them forever to do this. If it's like this for longer time - I'll compile and install them in my home dir, but that's hackish and errorprone. Today sablevm-classlib and sablevm-nativelib were accepted into archive, but unfortunatelly I overlooked some bit in sablevm and it got rejected (first time in my history) so it will take a moment longer. Anyway - it seems that the porting effort can be made a bit more "blindly" - the we can go by simply uploading "blindly ported" packages, letting autobuilders play with them and waiting for bugreports. We'll see. Summarizing: WoW! - thanks for the happy news! Best regards GBP |
From: Etienne M. G. <eti...@uq...> - 2002-08-22 13:32:15
|
Mark Wielaard wrote: > This seems to be it! ... > mark@multatuli:~$ /usr/local/sablevm/bin/sablevm-debug -Y Hello > Hello World! > > Yeah! If "Hello World" is possible everything else should be possible :) This is great news! As for the --classpath thing: SableVM uses a Java class loader to load application classes. More precisely, the starting point is the java.lang.VirtualMachine class which indirectly invokes the system class loader. The system class loader is the gnu.java.lang.SystemClassLoader class. It is often useful to print debug messages to identify problems, yet, in the VM's class library, invoking System.out.println() has MANY side effects, by potentially changing dramatically the flow of control (due to all the class loading and initialization it causes). For this reason, you will find very convenient "print" methods in the java.lang.VirtualMachine class. If you need them for debugging code in other packages (e.g. java.io.*), you will need to temporarily make the VirtualMachine class "public". Have fun! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne M. G. <eti...@uq...> - 2002-08-21 15:26:11
|
Hi Grzegorz, It would be interesting that you also generate method, instruction and exception traces as I have suggested to Mark, with the 1.0.3 version (with or without the xxx_Runtime.c patch). I'm really intrigued by the fact that 1.0.3 does not work for you, but 1.0.1 does. Maybe I should investigate using "cvs diff"... I'll give this a *brief* look. Etienne On Tue, Aug 20, 2002 at 11:53:14PM +0200, Grzegorz Prokopski wrote: > W li?cie z wto, 20-08-2002, godz. 23:30, Mark Wielaard pisze: > > Hi, > > > > On Tue, 2002-08-20 at 21:10, Grzegorz Prokopski wrote: > > > W li?cie z wto, 20-08-2002, godz. 20:55, Mark Wielaard pisze: > > > > I am going to try to update to the CVS version and try again. > > > If it fails - try 1.0.1 and report the result please. > > Then I downloaded the 1.0.1 versions: > > sablevm-1.0.1.tar.gz, sablevm-class-library-1.0.1.tar.gz and > > sablevm-native-library-1.0.1.tar.gz. > > Unpacked sablevm-1.0.1.tar.gz, unpacked the other two archives inside > > the sablevm-1.0.1 directory and replaced the system.h, system.c and > > jni_system_specific.h files with the patched CVS versions. This produced > > a binary that got a little bit further as can be seen in the attached > > output file but gives a java/lang/ExceptionInInitializerError at the > > end. > yes, but it got much further it seems. > > > I hope someone else will get better results. I will probably not have > > more time to play with this stuff before the weekend. If you have > > specific things you want me to try out please let me know, but I won't > > have time to debug this on my own right now. > I'd happily try it myself, but unfortunatelly debian machines admins > still haven't installed needed packages on the only PowerPC that is > freely available to debian developers. > [I don't have access to any other PowerPC machine] > > Idea: > The problem may be because the assemmbler part may not be working like > it should. If that's the case - please disable assember code for > a moment and try that "plain C" version of "test&swap" function (which > should never ever be used for real ;) > > Please pass --enable-debugging-features option to configure, so that > we knew you're using most "safe" settings. > > That's very simple test. > I am curious if that makes any difference and if results are always > the same for every run. > > Regards > > GBP > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz P. <gr...@se...> - 2002-09-06 08:53:14
|
W li=B6cie z wto, 20-08-2002, godz. 16:41, Grzegorz Prokopski pisze:=20 > Hi! >=20 > I updated debian packages to 1.0.3 version and now I am unable > to run even HelloWorld.jar. >=20 > Short output is this: >=20 > greg@greg:~$ java -jar HelloWorld.jar=20 > /usr/bin/sablevm -Y --classpath=3DHelloWorld.jar: HelloWorld > java/lang/UnsatisfiedLinkError Hi! I am back from (longer) vacations. I packaged sablevm 1.0.4. Just for the record - "it" happens in 1.0.4 version too. But I think I may now know what's happening. After installing 1.0.3 I strace shows things like this: open("/usr/lib/sablevm/libclasspath-1.0.1.so", O_RDONLY) =3D -1 ENOENT (No such file or directory) Note 1.0.1 number there! - no such file exists! When I am trying to use 1.0.4 it searches for libclasspath-1.0.3.so and other *1.0.3* files which don't exist! The question now is: am *I* messing sth? I couldn't find any "1.0.3" string in sources of nativelib or sablevm. Anyway - the facts I can observe are above. Hits? GBP PS: Gotta go out for a few hours now so I didn't do any extensive testing. But one thing I can tell you. If I install 1.0.4 and symlink all /usr/lib/sablevm/*1.0.4* to /usr/lib/sablevm/*1.0.3* names - "HelloWorld" works! |
From: Etienne M. G. <eti...@uq...> - 2002-09-06 13:24:59
|
Hi Grzegorz, Grzegorz Prokopski wrote: > Hi! > > I am back from (longer) vacations. I packaged sablevm 1.0.4. > > Just for the record - "it" happens in 1.0.4 version too. > > But I think I may now know what's happening. > After installing 1.0.3 I strace shows things like this: > > open("/usr/lib/sablevm/libclasspath-1.0.1.so", O_RDONLY) = -1 ENOENT (No > such file or directory) > > Note 1.0.1 number there! - no such file exists! > > When I am trying to use 1.0.4 it searches for libclasspath-1.0.3.so > and other *1.0.3* files which don't exist! > > The question now is: am *I* messing sth? I couldn't find any "1.0.3" > string in sources of nativelib or sablevm. Anyway - the facts I can > observe are above. > > Hits? The package version is managed by automake/autoconmf/build scripts. Presumably, you are not using an *unmodified* SableVM "build" script, so I guess your modified build procedure has some problems. You *must* rebuild all 3 sablevm[-*-library] packages for every new SableVM release. The symbolic links are made in part by autoconf scripts and in part by the "build" script. You are right on the fact that there is no version *embedded* into the source code: this is exactly what the author wanted, for easier maintenance. :) Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz P. <gr...@se...> - 2002-09-06 15:55:16
|
W li=B6cie z pi=B1, 06-09-2002, godz. 15:19, Etienne M. Gagnon pisze:=20 > The package version is managed by automake/autoconmf/build scripts. Pres= umably,=20 > you are not using an *unmodified* SableVM "build" script, so I guess your= =20 > modified build procedure has some problems. my build procedure for all the packages is simple:=20 ./configure; make; make install=20 with options about where put what - that's all=20 no magic at all=20 > You *must* rebuild all 3 sablevm[-*-library] packages for every new Sable= VM release. oh, sure I did ! > The symbolic links are made in part by autoconf scripts and in part by th= e=20 > "build" script. > You are right on the fact that there is no version *embedded* into the so= urce=20 > code: this is exactly what the author wanted, for easier maintenance. :) So where do these numbers come from then?=20 I removed all *sablevm* packages from my system, rebuilded, installed and problem still looks the same. But that's false impression(!) Now it looks for *1.0.4* libs where it should and finds them... with one exception [1]: open("/usr/lib/sablevm/libjava-lang-1.0.4.so", O_RDONLY) =3D -1 ENOENT (No such file or directory) How is that possible? don't know. But in just builded source tree I don't find this file anymore (but it exists in builded 1.0.3 source tree). So now, having all sablevm (non-working) packages installed I rebuilded 'native'. Oh f*** - it worked! - libjava-lang-1.0.4.so has been created! Of course after I install this new 'native' package - HelloWorld works well w/o any tricks. What would you say to that? My first impression is that the build process is flawed somewhere, as such things NEVER should take place, or at least should be very clearly documented. I will workaround it by declaring bulid-conflicts of sablevm with all sablevm packages and by build-depending of 'native' on 'sablevm' source resulting packages (no cyclic-build-deps). So, I belive that it works in _your_ environment, but the bug is somewhere there - don't you think? Now I am gonna fix 1.0.4 packages and upload them to NEW queue with the hope that ftpmasters will finally let it into the archive :-/ Cheers GBP [1] I was building all 3 sources in separate directiries, simultanously w/o having any sablevm binary/resulting package installed. |
From: Etienne M. G. <eti...@uq...> - 2002-09-06 20:55:51
|
Grzegorz Prokopski wrote: > my build procedure for all the packages is simple: > ./configure; make; make install > with options about where put what - that's all > no magic at all You're not giving any argument to "configure"? This won't work unless you're installing into /usr/local. This might be your problem. "configure" must be given the exact installation directory names (try configure --help). > > So where do these numbers come from then? From: 1) configure.ac 2) build[-*] scripts (variable VERSION) and (as a consequence of the above 1 & 2): 3) files generated by autoconf/automake: [*/]Makefile.in configure 4) files generated by "configure": [*/]/Makefile > I removed all *sablevm* packages from my system, rebuilded, installed > and problem still looks the same. But that's false impression(!) > Now it looks for *1.0.4* libs where it should and finds them... > with one exception [1]: >... > So now, having all sablevm (non-working) packages installed I rebuilded > 'native'. Oh f*** - it worked! - libjava-lang-1.0.4.so has been created! > > Of course after I install this new 'native' package - HelloWorld works > well w/o any tricks. > > What would you say to that? Check your build procedures, in light of the above information. > My first impression is that the build process is flawed somewhere, as > such things NEVER should take place, or at least should be very clearly > documented. I will workaround it by declaring bulid-conflicts of sablevm > with all sablevm packages and by build-depending of 'native' on > 'sablevm' source resulting packages (no cyclic-build-deps). I thought automake/autoconf were pretty much standard GNU tools... The only SableVM specific stuff is the "build" script. The remaining is more/less standard auto* stuff. Of course, you must always restart with a *fresh* working directory. If you had any leftover files from a previous installation (in your working directory), auto* tools might behave strangely. > > So, I belive that it works in _your_ environment, but the bug is > somewhere there - don't you think? Maybe, but you haven't convinced me yet. :-) > Now I am gonna fix 1.0.4 packages and upload them to NEW queue with > the hope that ftpmasters will finally let it into the archive :-/ Don't forget to be very friendly with our great fiends the ftpmasters. They like to feel important and respected... ;-))) Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |