harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "YangTing" <ti...@ali-mail.cs.umass.edu>
Subject [drlvm] Problem with running DRLVM on Fedora Core 5
Date Wed, 20 Sep 2006 00:24:36 GMT

   I checked out the lates classlib and drlvm source tree last night. I was 
able to build drlvm successfully. However, I encountered the following error 
when I tried to run DRLVM:

$ java
   Harmony Java launcher
   Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software 
Foundation or its licensors, as applicable.
   java [-vm:vmdll -vmdir:dir -D... [-X...]] [args]
   java: relocation error: 
symbol hythread_exit, version HYTHR_0.1 not defined in file libhythr.so with 
link time reference

If I try Hello.class, I got

$ ./java Hello

An unhandled error (4) has occurred.

I searched the email archive and jira entries, and fixed fat_monitor.c 
assertion problem based on Harmony-1340. I tried to unset JAVA_HOME, or set 
it to ...deploy/jre of drlvm, but still have the same problem.
I am using a Fedora core 5 linux box, with gcc version 4.1.0, and I was able 
to successfully build and run drlvm on the exact same machine about 2 months 
ago :-) Any ideas about what might be happening?

Thanks a lot!


BTW, when I was building DRLVM for the SVN head, I ran into a couple of 
minor issues (all from source code in jitrno/src):
1. jet/jet.cpp
    An extra line of "           \n" in the initializer of args[][2] (line 
290) causes a compilation failure
2. optimizer/reassociate.h
    Missing a statement "class Simplifier" at the beginning, which causes 
gcc to complain at line 79 ("friend class Simpilifier;")
3. jet/cg_meth.cpp
    At line 389, the statment "jt = jt = flt32 ? i32 : i64;" causes gcc to 
complain,  so I removed one "jt ="
4. codegenerator/ia32/Ia32Encoder.cpp
    At line 56, missing a pair of braces in the initializer of 
memOpndConstraints[16], which also causes a compilation error.
5. There a lot of warnings of "extra quantification" and "virutal class with 
non-virtual destructor" which are fairly easy to get around.

I am curious to know which is the most stable revision number for DRLVM ? 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message