I have found solution for this build problem. If somebody interested:
To use downloaded eclipse (or its compiler) need to run:
sh build.sh -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
But the compiler in theis eclipse version doesn't work with jre1.4, so
I need to change build.sh, removing:
CLASSPATH=$CLASSPATH:`pwd`/make/tmp/org.eclipse.jdt.core_3.1.1.jar
and changing:
CLASSPATH=`pwd`/make/tmp/cpptasks/cpptasks.jar:$CLASSPATH
in order to use CLASSPATH specified in command line environment. I
used ecj_3.2RC5 from classlib. After this, compilation works fine.
I run eclipse with the compiled drlvm and it started fine, except for
the message:
-------------------------------------------------------------------------------------------
Install location:
file:/home/ivan/experiments/harmony/drlvm/build/pre-copied/lnx/ECLIPSE/eclipse/
Configuration file:
file:/home/ivan/experiments/harmony/drlvm/build/pre-copied/lnx/ECLIPSE/eclipse/configuration/config.ini
loaded
java.lang.NoSuchMethodError: Can't find method
org/apache/harmony/kernel/vm/VM.bootCallerClassLoader()Ljava/lang/ClassLoader;
while resolving constant pool entry at index 74 in class
org/apache/harmony/luni/util/MsgHelp
at org.apache.harmony.luni.util.Msg.<clinit>(Msg.java:47)
at java.net.URL.<init>(URL.java:291)
at java.net.URL.<init>(URL.java:155)
at org.eclipse.core.launcher.Main.buildURL(Main.java:773)
at
org.eclipse.core.launcher.Main.getConfigurationLocation(Main.java:1210)
at org.eclipse.core.launcher.Main.processConfiguration(Main.java:1266)
at org.eclipse.core.launcher.Main.basicRun(Main.java:260)
at org.eclipse.core.launcher.Main.run(Main.java:973)
at org.eclipse.core.launcher.Main.main(Main.java:948)
Configuration location:
file:/home/ivan/experiments/harmony/drlvm/build/pre-copied/lnx/ECLIPSE/eclipse/configuration/
Framework located:
file:/home/ivan/experiments/harmony/drlvm/build/pre-copied/lnx/ECLIPSE/eclipse/plugins/org.eclipse.osgi_3.1.1.jar
Framework classpath:
file:/home/ivan/experiments/harmony/drlvm/build/pre-copied/lnx/ECLIPSE/eclipse/plugins/org.eclipse.osgi_3.1.1.jar
Debug options:
file:/home/ivan/experiments/harmony/drlvm/build/.options not found
Time to load bundles: 18
Starting application: 673
---------------------------------------------------------------------------------------------------------------
The exception is reproducible with and without Gregory's patch.
Gregory, is it the same problem you are working on?
--
Ivan
On 6/26/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
Stupid question. I am trying to compile current version of drlvm.
After a bunch of downloads which still remains (including huge
eclipse-3....gz) compilation failes with:
build.java:
[echo] ## Building Java classes of 'vm.kernel_classes'
[javac] Compiling 48 source files to
/home/ivan/experiments/harmony/drlvm/build/lnx_ia32_gcc_release/semis/vm/kernel_classes/_classes
[javac] javac: invalid target release: jsr14
[javac] Usage: javac <options> <source files>
[javac] where possible options include:
[javac] -g Generate all debugging info
[javac] -g:none Generate no debugging info
[javac] -g:{lines,vars,source} Generate only some debugging info
...............
I am using jdk-1.4 and rely on eclipse compiler everywhere. The
message means that compiler from jdk is used.
What for we download eclipse, if its compiler is ignored? :)
--
Ivan
On 6/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> Oops I forgot to write that the patch is in JIRA HARMONY-655.
>
> On Sunday 25 June 2006 22:46 Gregory Shimansky wrote:
> > On Sunday 25 June 2006 17:26 Mark Hindess wrote:
> > > On 24 June 2006 at 22:38, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > > > Mark Hindess wrote:
> > > > > On 24 June 2006 at 14:44, Gregory Shimansky <[EMAIL PROTECTED]>
> >
> > wrote:
> > > > >> Btw I've figured why kernel.jar has to be added to
> > > > >> bootclasspath.properties before luni.jar. They have many classes
> > > > >> with the same name but different code (Class, ClassLoader, Thread,
> > > > >> System, String to mention a few). So if luni.jar goes first in
> > > > >> bootclasspath, then all of those kernel classes implementations are
> > > > >> taken from classlib which isn't very good because they should be
> > > > >> taken from VM's kernel.jar. So there is no surprise that it doesn't
> > > > >> work.
> > > > >
> > > > > Oops... I can't believe we didn't spot this before! ...
> > > >
> > > > That's a regression :-( We used to specifically exclude the kernel
> > > > patternsets from each JAR packaging step. I agree that it should be
> > > > restored.
> > >
> > > Yes, it's definitely a regression. Probably at least partly my fault,
> > > so I've fixed it in r417017.
> > >
> > > Gregory, this should almost fix the ordering issue except for String
> > > which has moved out of the kernel classes in to luni. But as Tim says
> > > the real solution is to load the VM's versions of kernel classes first
> > > the same way the IBM VME does it.
> >
> > Sure I've created a patch to properties parser which adds kernel.jar
> > unconditionally to the beginning of bootclasspath, and filters out
> > everything which isn't beginning with bootclasspath.[0-9] so no *.source
> > and other properties appear in the property.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
