sablevm-developer Mailing List for SableVM (Page 56)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
| 2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
| 2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Etienne M. G. <eti...@uq...> - 2002-10-24 18:35:50
|
Hi Folks, On Wed, Oct 16, 2002 at 01:27:45PM +0200, Grzegorz Prokopski wrote: > I may be wrong - but it seems that there's something wrong w/ > createArray? So it is rather gnu classpath related problem not > SableVM? I was running some experiments, and I noticed that SableVM seemed broken; it wouldn't run the SPECjvm benchamrks anymore! (Complaining about the missing nativeCreateArray). So, after investigation, I finally found the problem: Jikes 1.17 generates internal class bytecodes which make these invocations, whereas Jikes 1.15 doesn't. On the short term, you should be using Jikes 1.15 (There's a package for it, I think, in Debian "testing"). Of course, I'll have to fix SableVM to implement the nativeCreateArray... On my TODO list (getting pretty long). Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne M. G. <eg...@j-...> - 2002-10-24 14:05:46
|
On Thu, Oct 24, 2002 at 02:45:34PM +0100, Toby Speight wrote: > Pretty much everything in AWT uses thread synchronisation somewhere or > other (I expect, not having examined classlib), so we're not going to > have a working AWT application for a while. :-( Threads and synchronizations ARE very much functional within SableVM. It's just the JNI "wrapper" that calls the internal synchro stuff that is yet missing. I'm just too busy at the moment (writing papers, teaching courses, catching up with all the late stuff that was delayed until I submitted my Ph.D. thesis late September). So, there's still some hope to get things up and running in the not too far future. What will help is when the evaluation of my thesis is done, as I will put it online, giving a nice reference for developers wanting to help write code within the VM itself. Etienne > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Toby S. <str...@gm...> - 2002-10-24 13:45:51
|
0> In article <103...@gr...>,
0> Grzegorz Prokopski <URL:mailto:gr...@se...> ("Grzegorz") wrote:
Grzegorz> OKay, it kinda worked, but now I am getting this (1.0.4):
Grzegorz>
Grzegorz> XXXXXXX TestAWT.class
Grzegorz> INSET:java.awt.Insets(top=0,bottom=0,left=0,right=0)
Grzegorz> loading gtkpeer
Grzegorz> init
Grzegorz> TRYING TO GET INTO GTKMAIN
Grzegorz> ACQUIRED LOCK TO RUN GTKMAIN
Grzegorz> 262
Grzegorz> sablevm: INTERNAL ERROR (source file "native_interface.c", line 24655):
Grzegorz> todo
Grzegorz> [and commandline returned w/o any effect]
I get the same with my simplest AWT test class (a Frame, a Label, and
a WindowAdapter) - we're now waiting for monitor_enter and friends to
be implemented in sablevm. Which is an improvement from a development
perspective, if not immediately useful to users.
Pretty much everything in AWT uses thread synchronisation somewhere or
other (I expect, not having examined classlib), so we're not going to
have a working AWT application for a while. :-(
|
|
From: Mark W. <ma...@kl...> - 2002-10-24 13:13:56
|
Hi, On Wed, 2002-10-16 at 13:27, Grzegorz Prokopski wrote: > > gjdoc is this: > exec java --classpath /usr/share/java/libgcj.jar -jar > /usr/share/java/gjdoc.jar "$@" Try removing the /usr/share/java/libgcj.jar from the classpath. Those are the core classes from gcj which are not (yet) the same as the GNU Classpath classes which are used with sablevm. > Mark Howard has done some work on this topic and reported that > he was able to run it with gcj *only* (compiled to native code). Yes this works very nicely. > or - the call to sablevm looked like this: > /usr/bin/sablevm -Y > --classpath=/usr/share/java/gjdoc.jar:/usr/share/java/libgcj.jar > gnu.classpath.tools.gjdoc.Main -doclet > gnu.classpath.tools.doclets.xmldoclet.Driver -sourcepath /tmp/gjdoc/ Here also, try to remove the libgcj.jar. Also note that currently gjdoc needs the sources of the core classes also on the sourcepath. (It should print a WARNING at the beginning about that.) > I may be wrong - but it seems that there's something wrong w/ > createArray? So it is rather gnu classpath related problem not > SableVM? createArray() looks like a SableVM addition to java.lang.ClassLoader which is not present in the upstream Classpath sources. Cheers, Mark |
|
From: Grzegorz P. <ga...@de...> - 2002-10-17 22:00:13
|
W li=B6cie z czw, 17-10-2002, godz. 22:22, Etienne M. Gagnon pisze:=20 > Hi Grzegorz, >=20 > I am unable to replicate your problem, but this is probably because all I= am=20 > doing is installing SableVM, not building a binary package (e.g. "./confi= gure;=20 > make; make install"). >=20 > Could you tell me how I can set up my environment to build a Debian packa= ge,=20 > replicating your problem? Sure. In some directory (for ex. deb-sablevm) - get current source from unstable: apt-get source sablevm sablevm-nativelib sablevm-classlib To ompile the source (you'll need this later): - change to source directroy (cd sablevm-1.0.5 for ex.) - issue dpkg-buildpackage -rfakeroot (note additional -d switch which will let you bypass build deps of the packages - or rather - build-conflicts) Above command runs clean, build install and binary targets of ./debian/rules Makefile. Calling: fakeroot ./debian/rules binary is almost the same (but it does not clean for ex.) How to check what the problems are: - remove all sablevm traces from your system (sablevm debian packages too if you created and installed your own) - apt-get install sablevm - this will install 1.0.4 version which is exactly what we need to get into trouble - put your sources of 1.0.5 into deb-sablevm dir (where you issued apt-get source) - go to debianized source dirs (sablevm-1.0.4, sablevm-nativelib-1.0.4, sablevm-classlib-1.0.4) one by one and issue sth. like uupdate ../sablevm-1.0.5.tar.gz uupdate ../sablevm-native-library-1.0.5.tar.gz uupdate ../sablevm-class-libarary-1.0.5.tar.gz Every uupdate call will unpack original source and apply debianizin patches. Some diffs will not apply (for ex. for autotools files, but those ones you can simply ignore - config.* files are copied from originals in /usr/share/misc/ if only you have autotools-dev package installed - you should have) then you can go to your newly debianized *1.0.5* dirs and issue dpkg-buildpackage -rfakeroot in every of them. [beware: in sablevm-classlib source in ./debian/rules change 1.0.4 to 1.0.5 in at the beginning of this makefile To get into trouble use -d switch which will let you compile the packages having *1.0.4* version installed. After compilation issue dpkg -i *1.0.5*.deb in deb-sable dir - to install your new version of packages. Try to run HelloWorld. And cry... This way you get into this: even that you compiled 1.0.5 version - some patches that sablevm will look for - will contain 1.0.4 Second trouble you can get into is this: - sablevm-nativelib will be nonfunctional, if you build it w/o having some version of sablevm-nativelib already installed on your system BTW: you may want to redirect output of every build to some output file, like this. dpkg-buildpackage -rfakeroot &>../output.native then tail -f ./output.native on another console I'd especially advice you to look for error: warning: strings that can show up At this very end - I almost forgot - you may find usefull to look at the content of debian-policy and debian-reference-en Hope it helps Grzegorz B. Prokopski PS: I just fetched and compiled 1.0.5 debian packages. ATM I can just say that they *don't* work. Will take closer look at this tomorrow. |
|
From: Etienne M. G. <eti...@uq...> - 2002-10-17 20:27:19
|
Hi Grzegorz, I am unable to replicate your problem, but this is probably because all I am doing is installing SableVM, not building a binary package (e.g. "./configure; make; make install"). Could you tell me how I can set up my environment to build a Debian package, replicating your problem? Thanks, Etienne Grzegorz Prokopski wrote: > Hi! > > I reported previously, that from sablevm-nativelib source some of the > libs are not build sometimes. So I made two builds - one w/o > old sablevm-native installed, one - with. And compared build > outputs. Here's what I found: > > --- ./native-installed.out 2002-09-08 22:17:47.000000000 +0200 > +++ ./native-uninstalled.out 2002-09-09 00:33:47.000000000 +0200 > > -/usr/bin/install -c .libs/libjava-io-1.0.4.soT > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-io-1.0.4.so > -(cd > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm && rm -f libjava-io.so && ln -s libjava-io-1.0.4.so libjava-io.so) > -/usr/bin/install -c .libs/libjava-io.lai > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-io.la > +/usr/bin/ld: cannot find -lclasspath > +collect2: ld returned 1 exit status > +libtool: install: error: relink `libjava-io.la' with the above command > before installing it > libtool: install: warning: remember to run `libtool --finish > /usr/lib/sablevm' > > -/usr/bin/install -c .libs/libjava-lang-1.0.4.soT > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-lang-1.0.4.so > -(cd > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm && rm -f libjava-lang.so && ln -s libjava-lang-1.0.4.so libjava-lang.so) > -/usr/bin/install -c .libs/libjava-lang.lai > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-lang.la > +/usr/bin/ld: cannot find -lclasspath > +collect2: ld returned 1 exit status > +libtool: install: error: relink `libjava-lang.la' with the above > command before installing it > libtool: install: warning: remember to run `libtool --finish > /usr/lib/sablevm' > > -/usr/bin/install -c .libs/libjava-net-1.0.4.soT > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-net-1.0.4.so > -(cd > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm && rm -f libjava-net.so && ln -s libjava-net-1.0.4.so libjava-net.so) > -/usr/bin/install -c .libs/libjava-net.lai > /home/greg/deb-pkgs/sablevm/sablevm-nativelib-1.0.4/debian/libsablevm-native1/usr/lib/sablevm/libjava-net.la > +/usr/bin/ld: cannot find -lclasspath > +collect2: ld returned 1 exit status > +libtool: install: error: relink `libjava-net.la' with the above command > before installing it > libtool: install: warning: remember to run `libtool --finish > /usr/lib/sablevm' > > Of course libclasspath is part of just built sablevm-nativelib and > in _no case_ should be looked for in /usr/lib ! > > So I suggest that: > 1. Such errors should be catched as errors and not ignored - should stop > compilation > 2. Some neat trick like LD_LIBRARY_PATH set to directory w/ just builded > libclasspath should be used (I'll try it in a minute) (btw. is it > portable outside Linux/glibc? no I think) > Maybe -L parameter usage would be wiser? Surely. > > Current situtation is that I need to have sablevm-nativelib installed > to be able build new sablevm-nativelib which is unnacceptable. > > Tell me what you think. > > GBP > > PS: The problem with sablevm-n.e.w looking for libs in o.l.d versions > if those o.l.d versions were installed during the build - seems to be > on similar ground. It seem that sablevm checks in /usr/lib, > /usr/lib/sablevm for versions first, instead of own build directories. > ATM I need to build conflict w/ sablevm and build depend on > libsablevm-native with specified version that coresponds to sablevm > version. > > > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > 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: Etienne M. G. <eti...@uq...> - 2002-10-17 00:54:16
|
Hi Grzegorz, I have made the 1.0.5 release, paying much attention to make as clean a build as possible (running all of the auto* stuff on a clean source tree). Can you check if you still get the Debian build problems with this version? If you still get these problems, then you'll have to tell me exactly about how you build your package. I guess I'll also have to learn about the Debian build procedures. Thanks, 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-10-16 11:27:57
|
Hi! Having properly installed sablevm (HelloWorld works) I tried to run gjdoc [1] and got this: greg@greg:~/deb-pkgs/gjdoc/markhoward$ (cd /tmp/gjdoc; gjdoc -doclet gnu.classpath.tools.doclets.xmldoclet.Driver -sourcepath /tmp/gjdoc/ $*) java.lang.NoClassDefFoundError: [Ljava/lang/String; at java.lang.ClassLoader.createArray(ClassLoader.java:417) at java.lang.ClassLoader.createArray(ClassLoader.java:340) at java.lang.Class.forName(Class.java:309) at java.lang.Class.forName(Class.java:268) at gnu.classpath.tools.gjdoc.Main.class$(Main.java) at gnu.classpath.tools.gjdoc.Main.startDoclet(Main.java:298) at gnu.classpath.tools.gjdoc.Main.start(Main.java:780) at gnu.classpath.tools.gjdoc.Main.main(Main.java:678) at java.lang.VirtualMachine.invokeMain(VirtualMachine.java) at java.lang.VirtualMachine.main(VirtualMachine.java:88) gjdoc is this: exec java --classpath /usr/share/java/libgcj.jar -jar /usr/share/java/gjdoc.jar "$@" gjdoc debian packages can be (temporarily) found at http://tildemh.com/tmp/gjdoc/ Mark Howard has done some work on this topic and reported that he was able to run it with gcj *only* (compiled to native code). [if you fetch the all_deb from there change gij in /usr/bin/gjdoc to java and setup your alternatives properly to use sablevm as java) or - the call to sablevm looked like this: /usr/bin/sablevm -Y --classpath=/usr/share/java/gjdoc.jar:/usr/share/java/libgcj.jar gnu.classpath.tools.gjdoc.Main -doclet gnu.classpath.tools.doclets.xmldoclet.Driver -sourcepath /tmp/gjdoc/ I may be wrong - but it seems that there's something wrong w/ createArray? So it is rather gnu classpath related problem not SableVM? Cheers Grzegorz B. Prokopski |
|
From: Grzegorz P. <gr...@se...> - 2002-10-15 23:03:13
|
W li=B6cie z pon, 14-10-2002, godz. 02:48, Etienne M. Gagnon pisze:=20 > On Fri, Oct 11, 2002 at 11:20:58PM +0200, Grzegorz Prokopski wrote: > > W li?cie z pi?, 11-10-2002, godz. 22:02, Etienne M. Gagnon pisze:=20 > > > 5- Solve the multiple-achitecture GNU auto* tools problems you are > > > raising in this message. > > Could you please move it to the front of the list? > I forgot to say: my list was *unordered*. I was just trying to sum up > all the "todo" work, and asking people for some ordering. I guess I > should put "5-" at the top. ;-) Yes, please. It is somewhat critical. And: 1. release more current 1.0.5 w/ ia64 and other your improvements 2. tell me what you think about totally-auto-config patch ( I agree that #if GNUC should stay, but what about the rest? the main?) ad 1. It's non-critilal - at least for me and I am more interested in ad 2. I'd like to push this thing further as the testing here will take time. We need to put the patch onto autobuilders, see what's breaking, fix stuff, upload again, package mauve, ask users of all arches to use mauve tests. Hmm... I just thought about sablevm-test package. It could build-dep on sablevm, mauve and other needed pieces and while building - it could just run all the tests we can be interested in. Of course it would be autobuilded (or I'd better say "autotested") on _all_ of debian architectures thus - making it easy to run any test we can dream of ;-)) I think I prepare the package quickly (this week) so that ftpmaster had time to let it in. Regards Grzegorz B. Prokopski |
|
From: Grzegorz P. <gr...@se...> - 2002-10-15 22:37:57
|
W li=B6cie z pon, 14-10-2002, godz. 12:57, Toby Speight pisze:=20 > With my patch, the GTK and GThread libraries are (dynamically) linked > in to satisfy dependencies on gdk_threads_mutex, gdk_root_window, > gthread_init, etc.: [...] > Yes, that's exactly the issue this patch solves. :-) OKay, it kinda worked, but now I am getting this (1.0.4): XXXXXXX TestAWT.class INSET:java.awt.Insets(top=3D0,bottom=3D0,left=3D0,right=3D0) loading gtkpeer init TRYING TO GET INTO GTKMAIN ACQUIRED LOCK TO RUN GTKMAIN 262 sablevm: INTERNAL ERROR (source file "native_interface.c", line 24655): todo [and commandline returned w/o any effect] XXXXXXX Test.class loading gtkpeer init TRYING TO GET INTO GTKMAIN ACQUIRED LOCK TO RUN GTKMAIN [and it seemed to eat 100% CPU here while hanging] I am attaching both (source) files used for testing. AFAIR they were in GNU ClassPath CVS repository, but were removed from there. Toby - do you have ANY (even trivial) Java app using AWT that runs w/ SableVM after applying your patch? Could you send it please? I would upload new 1.0.4 w/ your patch if I knew that it really helps to get anything really working. Best regards Grzegorz B. Prokopski PS: Etienne - please treat it as a bugreport (or feature request?) (I mean that INTERNAL ERROR above). You were saying you work on filling the holes in JNI interface, so maybe it's already fixed in your current version? |
|
From: Mark W. <ma...@kl...> - 2002-10-14 21:37:47
|
Hi, On Mon, 2002-10-14 at 22:30, Grzegorz Prokopski wrote: > It seems that conversation dried up in "Another small step on powerpc" > thread. No final conclusion was made AFAICS. Yes, sorry. I ran out of time. Learning and hacking powerpc assembly and figuring out calling conventions is fun but very time consuming. > However if you got Hello Word working what other problems arosed > (with bigger apps I suppose). Do you have any output of such problem? > (I mean things that work w/ SableVM on i386 but not powerpc). I don't have a powerpc build around at the moment. But also on x86 you get things like: sablevm: INTERNAL ERROR (source file "native_interface.c", line 24046): todo But I believe Etienne is working on those. > > I have not have the time check what does and what does not work since I > > am a bit busy at the moment. But now that Hello World works someone with > > some more PowerPC or endian knowledge should get most of SableVM > > working. > Huh - so you say we're having endianness problems w/ SableVM? > Hmm.. it seems that all - i386, alpha, ia64 have same endianness. > It is interesting how SableVM will work on new platforms after we add > auto-configure on Linux platforms. I believe there are some places that need investigating (like the one mentioned in my patch). It seems to be mainly passing arguments and getting results from calling native code through JNI that has some problems. Programs that don't use classes with native code seem to work OK. > > If you have time it would be interesting how much of the Mauve test > > suite you can get working on the different platforms. > > See http://source.redhat.com/mauve/. > Yes, I have just ITP:ed this test. > > After we have SableVM compiled on all arches - we'll have to ask > users (or rather debian developers) to test it. So it'll be needed > to have mauve test around in packaged form. Please let me know if you are going to use it. I can give pointers to results with Kissme, kaffe or gcj so you know what to expect (there are a couple of tests in Mauve that sadly fail on almost every VM and that I expect to be wrong in the first place). But there are a couple of Cheers, Mark |
|
From: Grzegorz P. <gr...@se...> - 2002-10-14 20:30:26
|
W li=B6cie z pi=B1, 11-10-2002, godz. 21:52, Mark Wielaard pisze:=20 > Hi, >=20 > On Fri, 2002-10-11 at 21:43, Grzegorz Prokopski wrote: > >=20 >=20 > > Questions: > > What stops us from getting PowerPC port ready? >=20 > The patches that I posted get "Hello World" working. > See > http://sourceforge.net/mailarchive/forum.php?thread_id=3D983089&forum_id= =3D4154 > http://sourceforge.net/mailarchive/forum.php?thread_id=3D1006086&forum_id= =3D4154 > But there are probably some other endian issues. It seems that conversation dried up in "Another small step on powerpc" thread. No final conclusion was made AFAICS. However if you got Hello Word working what other problems arosed (with bigger apps I suppose). Do you have any output of such problem? (I mean things that work w/ SableVM on i386 but not powerpc). > I have not have the time check what does and what does not work since I > am a bit busy at the moment. But now that Hello World works someone with > some more PowerPC or endian knowledge should get most of SableVM > working. Huh - so you say we're having endianness problems w/ SableVM? Hmm.. it seems that all - i386, alpha, ia64 have same endianness. It is interesting how SableVM will work on new platforms after we add auto-configure on Linux platforms. > If you have time it would be interesting how much of the Mauve test > suite you can get working on the different platforms. > See http://source.redhat.com/mauve/. Yes, I have just ITP:ed this test. After we have SableVM compiled on all arches - we'll have to ask users (or rather debian developers) to test it. So it'll be needed to have mauve test around in packaged form. Thanks for the pointer and all your effort Grzegorz B. Prokopski |
|
From: Etienne M. G. <eti...@uq...> - 2002-10-14 14:30:47
|
On Sun, Oct 13, 2002 at 09:14:40PM -0700, Archie Cobbs wrote: > FYI, >=20 > The patches that are currently required to get SableVM to compile > on FreeBSD are visible here: >=20 > http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablevm/files/ >=20 > The files are named 'patch-*' (ignore the 'extra-patch-*' files). >=20 > It would be nice if SableVM could be generalized enough that these > patches wouldn't be necessary. I'm sure NetBSD and OpenBSD require > similar fixes, so not just FreeBSD would benefit. Thanks for the link. I'll look at the patches and report back on this list. Etienne >=20 > I'd be happy to help test on FreeBSD if needed. >=20 > Cheers, > -Archie >=20 > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Toby S. <str...@gm...> - 2002-10-14 10:58:07
|
0> In article <103...@gr...>,
0> Grzegorz Prokopski <URL:mailto:gr...@se...> ("Grzegorz") wrote:
Grzegorz> W li=B6cie z pi=B1, 11-10-2002, godz. 21:43, Toby Speight =
pisze:
>> /--------
>> | loading gtkpeer
>> | java.lang.UnsatisfiedLinkError: Could not load library =
/usr/lib/sablevm/libgnu-java-awt-peer-gtk-1.0.1.so
>> | at java.lang.Runtime.load(Runtime.java:633)
>> | at java.lang.Runtime.loadLibrary(Runtime.java:656)
>> | at java.lang.System.loadLibrary(System.java:620)
>> | at gnu.java.awt.peer.gtk.GtkToolkit.static{}(GtkToolkit.java:74)
>> | ...
>> \--------
Grzegorz> Strange - why do I see 1.0.1 in above error (and 1.0.4 is
Grzegorz> mentioned as the "Version:")?
I cut-and-pasted from the wrong place (whilst investigating, Google
turned up your message at [1], and I accidentally copied from there
rather than from my shell buffer). I did indeed see 1.0.4 in the
error message. Sorry for causing confusion.
[1] =
<URL:http://sourceforge.net/mailarchive/forum.php?thread_id=3D999972&for=
um_id=3D4154>
>> I enclose a patch that adds the right dependencies (works for me).
Grzegorz> The more strange is why this didn't work and why your change
Grzegorz> fixes it. Are you sure that "just rebuilding" doesn't solve
Grzegorz> the problem?
Yes, I am sure that simply rebuilding doesn't solve it - that was the
first thing I tried. With the current 1.0.4, the GTK AWT library
doesn't refer to the libraries that provide GTK:
/--------
| .../sablevm-nativelib-1.0.4$ ldd =
debian/libsablevm-native1/usr/lib/sablevm/libgnu-java-awt-peer-gtk.so
| libc.so.6 =3D> /lib/libc.so.6 (0x4001d000)
| /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
\--------
With my patch, the GTK and GThread libraries are (dynamically) linked
in to satisfy dependencies on gdk_threads_mutex, gdk_root_window,
gthread_init, etc.:
/--------
| .../sablevm-nativelib-1.0.4-tms$ ldd =
debian/libsablevm-native1/usr/lib/sablevm/libgnu-java-awt-peer-gtk.so
| libgtk-1.2.so.0 =3D> /usr/lib/libgtk-1.2.so.0 (0x4001d000)
| libgdk-1.2.so.0 =3D> /usr/lib/libgdk-1.2.so.0 (0x40142000)
| libgmodule-1.2.so.0 =3D> /usr/lib/libgmodule-1.2.so.0 =
(0x40175000)
| libgthread-1.2.so.0 =3D> /usr/lib/libgthread-1.2.so.0 =
(0x40178000)
| libglib-1.2.so.0 =3D> /usr/lib/libglib-1.2.so.0 (0x4017b000)
| libpthread.so.0 =3D> /lib/libpthread.so.0 (0x4019d000)
| libdl.so.2 =3D> /lib/libdl.so.2 (0x401b2000)
| libXi.so.6 =3D> /usr/X11R6/lib/libXi.so.6 (0x401b5000)
| libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x401bd000)
| libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x401ca000)
| libm.so.6 =3D> /lib/libm.so.6 (0x40284000)
| libc.so.6 =3D> /lib/libc.so.6 (0x402a5000)
| /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
\--------
I arrived at my patch initially by adding the libraries one at a time
to Makefile each time I discovered an unresolved symbol, but luckily
I remembered the existence of gtk-config before moving the fix to
Makefile.in.
Grzegorz> I think it won't solve it (even if the versions were equal)
Grzegorz> and you experience the same thing as this:
Grzegorz> =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D999972&forum_id=
=3D4154
Yes, that's exactly the issue this patch solves. :-)
Grzegorz> PS: I am Cc:ing SableVM devel for eventuall comments.
I'm not on this list, so any questions, etc., for me should be CCed to =
me
(or to <16...@bu...> which I will check very infrequently).
N.B. - don't follow-up to <su...@bu...>!
|
|
From: Archie C. <ar...@de...> - 2002-10-14 04:30:15
|
Etienne M. Gagnon writes: > > If we had this, we could have all Linux arches "just" working. > > If there will be other arches, maybe non-linux that we want to > > support - we can always have #else - don't we? > > There seems to be a BSD version of SableVM floating around; so we > definitely need to provide an "#else" hook for these. FYI, The patches that are currently required to get SableVM to compile on FreeBSD are visible here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablevm/files/ The files are named 'patch-*' (ignore the 'extra-patch-*' files). It would be nice if SableVM could be generalized enough that these patches wouldn't be necessary. I'm sure NetBSD and OpenBSD require similar fixes, so not just FreeBSD would benefit. I'd be happy to help test on FreeBSD if needed. Cheers, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
|
From: Etienne M. G. <eti...@uq...> - 2002-10-14 01:12:27
|
On Sun, Oct 13, 2002 at 08:27:35PM +0200, Grzegorz Prokopski wrote: > > > > It might be nice to find a way to propagate the string retrieved from > > lt_dlerror back into the Java world, to give a more informative > > message for the exception. > Yes, it seems that SableVM has hard times delivering meaningful error > messages to the user (unfortunatelly). I hope it'll be improved > when more important problems are solved. We should definitely add this to the TODO list. 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-10-14 01:06:46
|
On Sun, Oct 13, 2002 at 12:46:47AM +0200, Grzegorz Prokopski wrote: > Hi! > > Below is my patch for having fully automatic configuration on > Linux (and probably other GNU-based) systems. Great! I'm starting to look at it. > > I don't think it's 100% suitable for new release. I'd like to > hear your comments on this. But IMO it's the right direction. So, here's what I'll do. I'll first check in your ia64 patch, make a release, then start playing with this code, and maybe check it into CVS if it seems good enough. > > I compiled the version for i386 and it worked. > Do you have any "cons" why I should _not_ upload such modified > version to Debian (to let it be tested on autobuilders for all 12 > architectures and so on) ? I would definitely prefer that the Debian version be based on an official SableVM release. I could maintain 2 SableVM branches: stable and experimental, which could help with experimentations. > PS: I removed some #if (defined (__GNUC__)) - I am not against > having such #ifs in future, when we support sth. more than __GNUC__, > but now - it's only bloat IMHO. I disagree. I see no reason for the switch threaded interpreter not to compile with an arbitrary ANSI/ISO C compiler, and I would like to keep it so. We can add "#else #error TODO" if you want, but I disagree to get rid of "#if (defined (__GNUC__))", as it hilights non-portable parts of the code. > I tried to keep the number if #ifs as low as possible. In fact - > there are some #if (defined __i386__) or __alpha__ that could be > removed too, but if we'd like to support systems w/o asm/system.h > in future - it may be good to keep it as it's now. (almost) There's no reason to "hide" non-portable code by removing such conditionals. I have explicitly put these in place to simplify porting to new systems. > Probably first non-Linux port (besides *BSD family) can > be MS Windows, so keeping at least i386 and ia64 seems resonable. I do not know how well MS Windows supports Posix Threads and libraries, but such a port would effectively be quite interesting. Beware that I will refer you to the GNU Classpath project for problems with the native libraries... ;-) > PSS: My approach with testing this code would be to just to upload > it to unstable and let the autobuilders do the rest. Then uplaod fixed > version and so on. After second try we should have all basic problems > solved. Then I could request testing on different arches at debian-java, > or maybe better - installation of the packages on all the machines > by deb...@de.... Let me a first make release with ia64 patch. Then I'll play with this new code. We could experiment with it a for a week or so before making a new release with this new code (possibly with some fixes). What do you think? 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-10-14 00:54:23
|
Hi Grzegorz, On Fri, Oct 11, 2002 at 11:20:58PM +0200, Grzegorz Prokopski wrote: > W li?cie z pi?, 11-10-2002, godz. 22:02, Etienne M. Gagnon pisze:=20 > > 5- Solve the multiple-achitecture GNU auto* tools problems you are > > raising in this message. > Could you please move it to the front of the list? I forgot to say: my list was *unordered*. I was just trying to sum up all the "todo" work, and asking people for some ordering. I guess I should put "5-" at the top. ;-) Etienne --=20 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-10-14 00:47:22
|
On Sat, Oct 12, 2002 at 02:31:43PM +0200, Grzegorz Prokopski wrote: > Would you apply a patch that makes all of the above automagic? > I mean: > - I can autodetect if this cmpxchg in asm/system.h is available > (I already have the patch using autotools) > - I can autodetect which types use for which needed sizes > (I already have the patch using autotools) > - I can autodetect page size (getpagesize), siezeof(void*) > and the helper values (see that small testing app I sent yesterday) > [I need to assume sth. about alignment unfortunatelly, like that > it's equal to machine word size] > > If we had this, we could have all Linux arches "just" working. > If there will be other arches, maybe non-linux that we want to > support - we can always have #else - don't we? There seems to be a BSD version of SableVM floating around; so we definitely need to provide an "#else" hook for these. > The same stands for some better support for certain architectures. > > But the aim is > "This program can be compiled on any Linux machine if it's dependencies > can be fulfilled" > > Do you think you would apply such patch if I prepared complete solution? I think so. -- 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-10-13 18:27:49
|
W li=B6cie z pi=B1, 11-10-2002, godz. 21:43, Toby Speight pisze:=20
> Package: libsablevm-native1
> Version: 1.0.4-1
> Severity: important
> Tags: patch
>=20
> When linking libgnu-java-awt-peer-gtk, its dependencies are not
> specified, meaning that it cannot be dynamically loaded at runtime,
> resulting in an UnsatisfiedLinkError at toolkit initialisation:
>=20
> /--------
> | loading gtkpeer
> | java.lang.UnsatisfiedLinkError: Could not load library /usr/lib/sablev=
m/libgnu-java-awt-peer-gtk-1.0.1.so
> | at java.lang.Runtime.load(Runtime.java:633)
> | at java.lang.Runtime.loadLibrary(Runtime.java:656)
> | at java.lang.System.loadLibrary(System.java:620)
> | at gnu.java.awt.peer.gtk.GtkToolkit.static{}(GtkToolkit.java:74)
> | ...
> \--------
Strange - why do I see 1.0.1 in above error (and 1.0.4 is mentioned as
the "Version:")?
I know that sablevm's build system has some problem that results
in exaclty such problems (runtime tries to load lib of another version
which was installed in the system during the build).
> I enclose a patch that adds the right dependencies (works for me).
The more strange is why this didn't work and why your change fixes it.
Are you sure that "just rebuilding" doesn't solve the problem?
I think it won't solve it (even if the versions were equal) and you
expirience the same thing as this:
http://sourceforge.net/mailarchive/forum.php?thread_id=3D999972&forum_id=3D=
4154
> I'm not an automake wizard by any means, so it's possible that the
> ld flags for the GTK libraries could be put into @LDFLAGS@ rather
> than into Makefile.in, but if that's the case then this should at
> least give you a start.
>=20
> My Java program needs a java.awt.Image implementation, so it falls over
> when it looks for libgnu-java-awt-image, but it definitely manages to
> load libgnu-java-awt-peer-gtk. (Sadly, I can't contribute to the image
> implementation because I use Sun-licensed Java sources at work).
>=20
> When debugging this, I found it helpful to retrieve and print the
> error message from lt_dlopen by adding some following lines at line
> 211 of java_lang_Runtime.c in the sablevm package giving the following
> replacement for the handle=3D=3DNULL test:
>=20
> /--------
> | if (handle =3D=3D NULL)
> | {
> | char *error =3D lt_dlerror();
> | if (error)
> | _svmf_printf (env, stdout, "lt_dlopen: %s\n", error);
> | else
> | _svmf_printf (env, stdout, "lt_dlopen: NULL\n");
> | _svmm_gfree_utf_chars (filename);
> | goto end;
> | }
> \--------
>=20
>=20
> It might be nice to find a way to propagate the string retrieved from
> lt_dlerror back into the Java world, to give a more informative
> message for the exception.
Yes, it seems that SableVM has hard times delivering meaningful error
messages to the user (unfortunatelly). I hope it'll be improved
when more important problems are solved.
> --- sablevm-nativelib-1.0.4/src/gnu-java-awt-peer-gtk/Makefile.in 2=
002-08-24 17:22:57 +0100
> +++ sablevm-nativelib-1.0.4-tms/src/gnu-java-awt-peer-gtk/Makefile.in 2=
002-10-11 20:10:18 +0100
> @@ -174,7 +174,7 @@
> DEFS =3D @DEFS@
> DEFAULT_INCLUDES =3D -I. -I$(srcdir) -I$(top_builddir)/src/include
> CPPFLAGS =3D @CPPFLAGS@
> -LDFLAGS =3D @LDFLAGS@
> +LDFLAGS =3D @LDFLAGS@ $(shell gtk-config --libs gtk gthread)
> LIBS =3D @LIBS@
> depcomp =3D $(SHELL) $(top_srcdir)/depcomp
> am__depfiles_maybe =3D depfiles
I'll try to check this problem (and your solution) soon and report
my expiriences.
Thanks for the patch.=20
Best regards
Grzegorz B. Prokopski
PS: I am Cc:ing SableVM devel for eventuall comments.
For ex. is the approach w/ calling gtk-config right and eventually
how should it be done in more "autotoolsed" way?
|
|
From: Grzegorz P. <gr...@se...> - 2002-10-12 22:47:21
|
Hi!
Below is my patch for having fully automatic configuration on
Linux (and probably other GNU-based) systems.
I don't think it's 100% suitable for new release. I'd like to
hear your comments on this. But IMO it's the right direction.
I compiled the version for i386 and it worked.
Do you have any "cons" why I should _not_ upload such modified
version to Debian (to let it be tested on autobuilders for all 12
architectures and so on) ?
Any comments?
GBP
PS: I removed some #if (defined (__GNUC__)) - I am not against
having such #ifs in future, when we support sth. more than __GNUC__,
but now - it's only bloat IMHO.
I tried to keep the number if #ifs as low as possible. In fact -
there are some #if (defined __i386__) or __alpha__ that could be
removed too, but if we'd like to support systems w/o asm/system.h
in future - it may be good to keep it as it's now. (almost)
Probably first non-Linux port (besides *BSD family) can
be MS Windows, so keeping at least i386 and ia64 seems resonable.
PSS: My approach with testing this code would be to just to upload
it to unstable and let the autobuilders do the rest. Then uplaod fixed
version and so on. After second try we should have all basic problems
solved. Then I could request testing on different arches at debian-java,
or maybe better - installation of the packages on all the machines
by deb...@de....
--- ./sablevm-1.0.4/configure.ac 2002-08-24 17:48:32.000000000
+0200
+++ ./sablevm-1.0.4-fullauto/configure.ac 2002-10-12
23:53:54.000000000 +0200
@@ -165,6 +165,10 @@
fi
fi
+dnl By GBP +
+AC_CHECK_DECLS(cmpxchg,,,[#include <asm/system.h>] )
+
+dnl By GBP -
dnl -Wid-clash-LEN -Wlarger-than-LEN -Wredundant-decls -Wconversion
-Wcast-qual
dnl -Wmissing-noreturn -Wtraditional -Waggregate-return -ansi
-pedantic -Wunreachable-code
@@ -175,4 +179,147 @@
src/libsablevm/include/Makefile
src/sablevm/Makefile])
+dnl Automagically check sizes of certain types
+AC_CHECK_SIZEOF(void*)
+AC_CHECK_SIZEOF(unsigned char)
+AC_CHECK_SIZEOF(signed char)
+AC_CHECK_SIZEOF(unsigned short)
+AC_CHECK_SIZEOF(signed short)
+AC_CHECK_SIZEOF(unsigned int)
+AC_CHECK_SIZEOF(signed int)
+AC_CHECK_SIZEOF(unsigned long long)
+AC_CHECK_SIZEOF(signed long long)
+AC_CHECK_SIZEOF(float)
+AC_CHECK_SIZEOF(double)
+
+if test "$ac_cv_sizeof_unsigned_char" -eq 1; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_U8, unsigned char, "Autodetected
1byte/8bit unsigned int")
+ if test "$ac_cv_sizeof_unsigned_char" -eq "$ac_cv_sizeof_voidp";
then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD, unsigned char, "Autodetected
unsinged int of void* size")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_SIZE, 1)
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_BIT_COUNT, 8)
+ fi
+else
+ AC_MSG_ERROR("Unable to find 1byte/8bit unsigned int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_signed_char" -eq 1; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_S8, signed char, "Autodetected
1byte/8bit signed int")
+else
+ AC_MSG_ERROR("Unable to find 1byte/8bit signed int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_unsigned_short" -eq 2; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_U16, unsigned short, "Autodetected
1byte/16bit unsigned int")
+ if test "$ac_cv_sizeof_unsigned_short" -eq "$ac_cv_sizeof_voidp";
then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD, unsigned int, "Autodetected
unsinged int of void* size")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_SIZE, 2, "sizeof(void*)")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_BIT_COUNT, 16, "sizeof(void*)
in bits")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_ALIGNMENT, AUTO_SVMT_WORD_SIZE,
"alignment for this processor")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_ALIGNMENT_POWER, 1, "alignment for
this processor expressed in power of 2")
+ fi
+else
+ AC_MSG_ERROR("Unable to find 2byte/16bit unsigned int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_signed_short" -eq 2; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_S16, signed short, "Autodetected
2byte/16bit signed int")
+else
+ AC_MSG_ERROR("Unable to find 2byte/16bit signed int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_unsigned_int" -eq 4; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_U32, unsigned int, "Autodetected
4byte/32bit unsigned int")
+ if test "$ac_cv_sizeof_unsigned_int" -eq "$ac_cv_sizeof_voidp";
then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD, unsigned int, "Autodetected
unsinged int of void* size")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_SIZE, 4, "sizeof(void*)")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_BIT_COUNT, 32, "sizeof(void*)
in bits")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_ALIGNMENT, AUTO_SVMT_WORD_SIZE,
"alignment for this processor")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_ALIGNMENT_POWER, 2, "alignment for
this processor expressed in power of 2")
+ fi
+else
+ AC_MSG_ERROR("Unable to find 4byte/32bit unsigned int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_signed_int" -eq 4; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_S32, signed int, "Autodetected
4byte/32bit signed int")
+else
+ AC_MSG_ERROR("Unable to find 4byte/32bit signed int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_unsigned_long_long" -eq 8; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_U64, unsigned long long, "Autodetected
8byte/64bit unsigned int")
+ if test "$ac_cv_sizeof_unsigned_long_long" -eq
"$ac_cv_sizeof_voidp"; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD, unsigned long long,
"Autodetected unsinged int of void* size")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_SIZE, 8, "sizeof(void*)")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_WORD_BIT_COUNT, 64, "sizeof(void*)
in bits")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_ALIGNMENT, AUTO_SVMT_WORD_SIZE,
"alignment for this processor")
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_ALIGNMENT_POWER, 3, "alignment for
this processor expressed in power of 2")
+ fi
+else
+ AC_MSG_ERROR("Unable to find 8byte/64bit unsigned int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_signed_long_long" -eq 8; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_S64, signed long long, "Autodetected
8byte/64bit signed int")
+else
+ AC_MSG_ERROR("Unable to find 8byte/64bit signed int for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_float" -eq "4"; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_F32, float, "Autodetected 4byte/32bit
float")
+else
+ AC_MSG_ERROR("Unable to find 4byte/32bit float for this
architecture")
+fi
+
+if test "$ac_cv_sizeof_double" -eq "8"; then
+ AC_DEFINE_UNQUOTED(AUTO_SVMT_D64, double, "Autodetected 8byte/64bit
double")
+else
+ AC_MSG_ERROR("Unable to find 8byte/64bit double for this
architecture")
+fi
+
+dnl Check if we can use cmpxchg from asm/system.h
+
+dnl AC_CHECK_DECLS (cmpxchg,,,[#include <asm/system.h>])
+AC_CHECK_DECLS(cmpxchg,,,[#include <asm/system.h>] )
+
+dnl Check if we can use getpagesize and get it's result
+dnl sorry, this can't be crosscompiled
+if test "$ac_cv_func_getpagesize" = "yes"; then
+ echo -n "getpagesize found, checking result... " >&5
+ echo -n "getpagesize found, checking result... " >&6
+ cat >conftest.$ac_ext <<_ACEOF
+#include <unistd.h>
+int main() {
+ int result;
+ result = getpagesize();
+ printf("%i", result);
+ return 1;
+}
+_ACEOF
+ rm -f conftest.$ac_objext conftest$ac_exeext
+ if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+ (eval $ac_link) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+ { ac_try='test -s conftest$ac_exeext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ac_result=`./conftest$ac_exeext`
+ echo "$ac_result" >&5
+ echo "$ac_result" >&6
+ AC_DEFINE_UNQUOTED(GETPAGESIZE_RESULT, $ac_result,
"getpagesize result (0 if nonavail)")
+ else
+ echo "$as_me: failed program was:" >&5
+ cat conftest.$ac_ext >&5
+ eval "$as_ac_var=no"
+ AC_DEFINE_UNQUOTED(GETPAGESIZE_RESULT, 0, "getpagesize
result (0 if nonavail)")
+ fi
+else
+ AC_DEFINE_UNQUOTED(GETPAGESIZE_RESULT, 0, "getpagesize result (0
if nonavail)")
+fi
+
AC_OUTPUT
--- ./sablevm-1.0.4/src/libsablevm/include/jni_system_specific.h
2002-08-15 07:29:54.000000000 +0200
+++
./sablevm-1.0.4-fullauto/src/libsablevm/include/jni_system_specific.h 2002-10-12 20:09:45.000000000 +0200
@@ -13,28 +13,21 @@
8,16,32,64 = 8 bits, 16 bits, ...
So, "u8" means an 8 bits unsigned integer. */
-/* alpha and i386 are identical here */
-
-#if ((defined (__alpha__) || defined (__i386__)) && defined (__GNUC__))
-
#define JNICALL
#define JNIEXPORT
-typedef unsigned char _svmt_u8;
-typedef signed char _svmt_s8;
-typedef unsigned short _svmt_u16;
-typedef signed short _svmt_s16;
-typedef unsigned int _svmt_u32;
-typedef signed int _svmt_s32;
-__extension__ typedef unsigned long long _svmt_u64;
-__extension__ typedef signed long long _svmt_s64;
-typedef float _svmt_f32;
-typedef double _svmt_d64;
-
-#else
+/* the AUTO_SVMT_* defines are detected at ./configure stage */
-#error "unknown system"
+typedef AUTO_SVMT_U8 _svmt_u8;
+typedef AUTO_SVMT_S8 _svmt_s8;
+typedef AUTO_SVMT_U16 _svmt_u16;
+typedef AUTO_SVMT_S16 _svmt_s16;
+typedef AUTO_SVMT_U32 _svmt_u32;
+typedef AUTO_SVMT_S32 _svmt_s32;
+__extension__ typedef AUTO_SVMT_U64 _svmt_u64;
+__extension__ typedef AUTO_SVMT_S64 _svmt_s64;
+typedef AUTO_SVMT_F32 _svmt_f32;
+typedef AUTO_SVMT_D64 _svmt_d64;
-#endif
#endif /* NOT SVM_JNI_SYSTEM_SPECIFIC_H */
--- ./sablevm-1.0.4/src/libsablevm/system.c 2002-08-19
07:16:06.000000000 +0200
+++ ./sablevm-1.0.4-fullauto/src/libsablevm/system.c 2002-10-13
00:26:45.000000000 +0200
@@ -5,8 +5,6 @@
* modification of SableVM. *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
-#if ((defined (__alpha__) || defined (__i386__)) && defined (__GNUC__))
-
/*
----------------------------------------------------------------------
_svmf_iflush
@@ -29,7 +27,9 @@
#elif defined(__i386__)
/* do nothing */
#else
-#error
+ /* just do nothing by default, as we're on the safe side of threading
kind by default
+ BTW: can we issue a #warning here somehow?
+ #error */
#endif
}
@@ -61,8 +61,12 @@
{
/* Yes, some inline assembly source code... Unfortunaltely, this
cannot be expressed in C. */
+#if HAVE_DECL_CMPXCHG
+#include <asm/system.h>
+ int result;
+ result = (cmpxchg((pword), (old_value), (new_value)) ==
(old_value));
-#if defined (__i386__)
+#elif defined (__i386__)
/* On the ia32, cmpxchgl has a side effect. When swapping fails,
the following variable contains the value that is currently in
*pword (presumably different from old_value). */
@@ -77,9 +81,7 @@
:"r" (new_value), "m" (*pword), "a" (old_value)
:"memory");
/* *INDENT-ON* */
-#endif
-
-#if (defined (__alpha__))
+#elif (defined (__alpha__))
register _svmt_word result, tmp;
/* *INDENT-OFF* */
@@ -645,5 +647,3 @@
#endif
}
-
-#endif /* (defined (__i386__) && defined (__GNUC__)) */
--- ./sablevm-1.0.4/src/libsablevm/system.h 2002-08-15
07:29:54.000000000 +0200
+++ ./sablevm-1.0.4-fullauto/src/libsablevm/system.h 2002-10-13
00:25:39.000000000 +0200
@@ -48,7 +48,7 @@
*/
-#if ((defined (__alpha__) || defined (__i386__)) && defined (__GNUC__))
+#if (defined (__GNUC__))
/* "inline" is now an official keyword since the latest C standard
(1999).
So, it is a reasonable assuption to expect a target compiler to
@@ -64,7 +64,18 @@
* I guess that on most architectures, an "unsigned int" is a "word".
*/
-#if defined (__i386)
+#if ( GETPAGESIZE_RESULT && AUTO_SVMT_WORD_SIZE &&
AUTO_SVMT_WORD_BIT_COUNT \
+ && AUTO_SVMT_ALIGNMENT && AUTO_SVMT_ALIGNMENT_POWER )
+
+typedef AUTO_SVMT_WORD _svmt_word;
+#define SVM_WORD_SIZE AUTO_SVMT_WORD_SIZE
+#define SVM_WORD_BIT_COUNT AUTO_SVMT_WORD_BIT_COUNT
+
+#define SVM_ALIGNMENT AUTO_SVMT_ALIGNMENT
+#define SVM_ALIGNMENT_POWER AUTO_SVMT_ALIGNMENT_POWER
+#define SMV_PAGE_SIZE GETPAGESIZE_RESULT
+
+#elif defined (__i386__)
typedef _svmt_u32 _svmt_word;
|
|
From: Grzegorz P. <gr...@se...> - 2002-10-12 12:31:58
|
W li=B6cie z pi=B1, 11-10-2002, godz. 21:37, Etienne M. Gagnon pisze:=20 > On Fri, Oct 11, 2002 at 09:28:22PM +0200, Grzegorz Prokopski wrote: > > We could have all Linux arches supported in 24 hours! ;-) > > Why shouldn't we use it? >=20 > As long as we add a "#ifdef LINUX" (or the equivalent), we could do it. But there's nothing wrong it supporting all Linux arches out-of-the box, even without any manual intervention to add new ones. We can autodetect almost all we need. The current approach is that we have separate pieces of code, that define: - assembler parts - integer/float type sizes - page size, alignment size and helper values based on them Would you apply a patch that makes all of the above automagic? I mean: - I can autodetect if this cmpxchg in asm/system.h is available (I already have the patch using autotools) - I can autodetect which types use for which needed sizes (I already have the patch using autotools) - I can autodetect page size (getpagesize), siezeof(void*) and the helper values (see that small testing app I sent yesterday) [I need to assume sth. about alignment unfortunatelly, like that it's equal to machine word size] If we had this, we could have all Linux arches "just" working. If there will be other arches, maybe non-linux that we want to support - we can always have #else - don't we? The same stands for some better support for certain architectures. But the aim is "This program can be compiled on any Linux machine if it's dependencies can be fulfilled" Do you think you would apply such patch if I prepared complete solution? > Is there an equivalent for "iflush()"? Then we would get the > inline-threaded engine to work too... :) I haven't looked at it yet. Regards GBP |
|
From: Grzegorz P. <gr...@se...> - 2002-10-11 21:21:10
|
W li=B6cie z pi=B1, 11-10-2002, godz. 22:02, Etienne M. Gagnon pisze:=20 > 5- Solve the multiple-achitecture GNU auto* tools problems you are > raising in this message. Could you please move it to the front of the list? I'd very much like to soon upload version which compiles on all arches, on which build-deps are fulfilled. And it would be *very* bad to be forced to workaround this self-build-dep thing. > 6- Port SableVM to all (or most) Debian architectures. It's mine topic for now, so on your list it can stay where it is. > 7- Make sure the "inline-threaded" engine woks on all these > architectures. I hope to work together on this topic. > > 4. What will be needed to get this "faster" threading engine > > working on non-i386 arches? (where should I start?) > First, we need an "iflush()" on them. Then, it depends. It might > work out-of-the box on some architectures, or some others might > require playing with the "INLINEABLE" property of some bytecodes > (instructions.m4.c). I'll have to learn more about that asm code for powerpc to catch how to implement it on other arches. > OK, I'll be checking mail only on Sunday. Have fun! Sure, I am busy too. I have second studies to study on weekends too. Best regards GBP |
|
From: Etienne M. G. <eti...@uq...> - 2002-10-11 20:11:57
|
On Fri, Oct 11, 2002 at 09:43:28PM +0200, Grzegorz Prokopski wrote: > 2. There are still problems w/ -native build-depending on > itself. It's very annoying especially while porting to new arches ... > Any ideas how to fix it? > Etienne - do you have plans to remove this issue? > If yes - when can it be expected to happen? I have to understand the problem, first. As I don't have an infinite amount of time to work on all issues, we will have to start prioritizing tasks. I currently see the following things to do: 1- Fill the holes in reflexion support for getting the most important Debian Java apps to work (or at least "Ant"). 2- Fill the holes in JNI and Invocation Interface (e.g. clean DestroyVM, etc.) 3- Look at the AWT stuff, and see if we can get some of it to work. 4- Discuss some formatting issues (e.g. indentation, directory structure) with the Classpath project so that official Classpath could work out-of-the-box with SableVM. 5- Solve the multiple-achitecture GNU auto* tools problems you are raising in this message. 6- Port SableVM to all (or most) Debian architectures. 7- Make sure the "inline-threaded" engine woks on all these architectures. Here are the main points I see for the moment. Have I forgotten anything? > 4. What will be needed to get this "faster" threading engine > working on non-i386 arches? (where should I start?) First, we need an "iflush()" on them. Then, it depends. It might work out-of-the box on some architectures, or some others might require playing with the "INLINEABLE" property of some bytecodes (instructions.m4.c). OK, I'll be checking mail only on Sunday. Have fun! Etienne > > Best reagards > > Grzegorz B. Prokopski > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > 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: Mark W. <ma...@kl...> - 2002-10-11 19:52:39
|
Hi, On Fri, 2002-10-11 at 21:43, Grzegorz Prokopski wrote: > > Questions: > What stops us from getting PowerPC port ready? The patches that I posted get "Hello World" working. See http://sourceforge.net/mailarchive/forum.php?thread_id=983089&forum_id=4154 http://sourceforge.net/mailarchive/forum.php?thread_id=1006086&forum_id=4154 But there are probably some other endian issues. I have not have the time check what does and what does not work since I am a bit busy at the moment. But now that Hello World works someone with some more PowerPC or endian knowledge should get most of SableVM working. If you have time it would be interesting how much of the Mauve test suite you can get working on the different platforms. See http://source.redhat.com/mauve/. Cheers, Mark |
6 messages has been excluded from this view by a project administrator.
