You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Christian Schröder <cs...@deriva.de> on 2008/02/22 15:30:18 UTC
Cross-compilation problem
Hi list,
I have some projects that should be compiled with javac 1.4 and some
that should be compiled with javac 1.5. Since I do not want to change my
environment between the projects, I have the JAVA_HOME variable set to
the 1.5 classpath and want ant to use the external 1.4 javac when
necessary. Unfortunately, I always get an "Error running
/usr/java/j2sdk1.4.2/bin/javac compiler".
I have been able to create a small example build file to reproduce this
problem:
<?xml version="1.0" encoding="UTF-8"?>
<project name="TestProject" default="default" basedir=".">
<target name="default">
<javac srcdir="src" destdir="classes" source="1.4" target="1.4"
fork="yes" executable="/usr/java/j2sdk1.4.2/bin/javac"/>
</target>
</project>
With verbose output I get the following stack trace:
/home/chschroe/deriva/projects/DerivaLibLogging/build-tmp.xml:4: Error
running /usr/java/j2sdk1.4.2/bin/javac compiler
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:509)
at
org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute(JavacExternal.java:61)
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:997)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:820)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by: java.io.IOException: java.io.IOException: Cannot allocate memory
at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec(Execute.java:828)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:445)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:459)
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:506)
... 20 more
The machine has several gigs of free memory and this test project is
really small. So what's the problem?
Some information about my environment:
Apache Ant version 1.7.0 compiled on December 13 2006
javac 1.5.0_12
javac 1.4.2_15
Thanks for all help!
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT and Consulting Fax: +49 551 489500-91
Hans-Böckler-Straße 2 http://www.deriva.de
D-37079 Göttingen
Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Cross-compilation problem
Posted by Robin Chaddock <ro...@iplay.com>.
Do you experience the same problem if you by-pass the javac task, and
invoke javac using the exec task?
Obviously not a very nice work-around... but if it solves your
problem.... :>.
Scot P. Floess wrote:
> That's really interesting! To be honest I have not really had a need
> to do something like that to date...
>
> I'll have to give this some more thought...
>
>
> Christian Schröder wrote:
>> Scot P. Floess wrote:
>>> Curious, why don't you just use the 1.5 javac but target 1.4? That
>>> should do what you want... I think all you will need to do is this:
>>>
>>> <javac srcdir="src" destdir="classes" source="1.4" target="1.4"/>
>> The problem is that the 1.5 javac won't complain if I accidently use
>> functions from the 1.5 api. It will create a class file which *looks*
>> like 1.4 (as to the class version number), but cannot be executed by
>> a 1.4 jvm.
>> Try the following example:
>>
>> public class Test {
>> public static void main(String[] args) {
>> String s = "Hello World";
>> int i = s.codePointAt(0);
>> }
>> }
>>
>> If I compile with "/usr/java/jdk1.5.0/bin/javac -source 1.4 -target
>> 1.4 Test.java" the compiler won't complain. However, if I start this
>> app with a 1.4 jvm I get the following exception:
>>
>> Exception in thread "main" java.lang.NoSuchMethodError:
>> java.lang.String.codePointAt(I)I
>> at Test.main(Test.java:4)
>>
>> The 1.4 compiler would have reported the following error:
>>
>> Test.java:4: cannot resolve symbol
>> symbol : method codePointAt (int)
>> location: class java.lang.String
>> int i = s.codePointAt(0);
>> ^
>> 1 error
>>
>> That's why I try to use the compiler of the target platform.
>>
>> Regards,
>> Christian
>>
>
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Cross-compilation problem
Posted by "Scot P. Floess" <fl...@mindspring.com>.
That's really interesting! To be honest I have not really had a need to
do something like that to date...
I'll have to give this some more thought...
Christian Schröder wrote:
> Scot P. Floess wrote:
>> Curious, why don't you just use the 1.5 javac but target 1.4? That
>> should do what you want... I think all you will need to do is this:
>>
>> <javac srcdir="src" destdir="classes" source="1.4" target="1.4"/>
> The problem is that the 1.5 javac won't complain if I accidently use
> functions from the 1.5 api. It will create a class file which *looks*
> like 1.4 (as to the class version number), but cannot be executed by a
> 1.4 jvm.
> Try the following example:
>
> public class Test {
> public static void main(String[] args) {
> String s = "Hello World";
> int i = s.codePointAt(0);
> }
> }
>
> If I compile with "/usr/java/jdk1.5.0/bin/javac -source 1.4 -target
> 1.4 Test.java" the compiler won't complain. However, if I start this
> app with a 1.4 jvm I get the following exception:
>
> Exception in thread "main" java.lang.NoSuchMethodError:
> java.lang.String.codePointAt(I)I
> at Test.main(Test.java:4)
>
> The 1.4 compiler would have reported the following error:
>
> Test.java:4: cannot resolve symbol
> symbol : method codePointAt (int)
> location: class java.lang.String
> int i = s.codePointAt(0);
> ^
> 1 error
>
> That's why I try to use the compiler of the target platform.
>
> Regards,
> Christian
>
--
Scot P. Floess
27 Lake Royale
Louisburg, NC 27549
252-478-8087 (Home)
919-754-4592 (Work)
Chief Architect JPlate http://sourceforge.net/projects/jplate
Chief Architect JavaPIM http://sourceforge.net/projects/javapim
Architect Keros http://sourceforge.net/projects/keros
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Cross-compilation problem
Posted by Chad McHenry <mc...@gmail.com>.
On Fri, Feb 22, 2008 at 12:46 PM, Christian Schröder <cs...@deriva.de> wrote:
> Scot P. Floess wrote:
> > Curious, why don't you just use the 1.5 javac but target 1.4? That
> > should do what you want... I think all you will need to do is this:
>
> <javac srcdir="src" destdir="classes" source="1.4" target="1.4"/>
> The problem is that the 1.5 javac won't complain if I accidently use
> functions from the 1.5 api.
I've also had to do this. You'll need to specify the "compiler" and
"executable" attributes of the javac task. Using your Test example, this
build file will compile with 1.5, but fail with 1.4. I don't use the
"source" or "target" attributes of javac, since each compilers default
output is what I want. Setting fork="true" is required to use a different
compiler.
...Chad
<project name="compiler-test" default="build">
<target name="build">
<antcall target="compile">
<param name="compiler.id" value="javac1.5"/>
<param name="compiler.exe" value="C:/java/jdk1.5.0_14/bin/javac.exe"/>
</antcall>
<antcall target="compile">
<param name="compiler.id" value="javac1.4"/>
<param name="compiler.exe" value="C:/java/jdk1.4.2_16/bin/javac.exe"/>
</antcall>
</target>
<target name="compile">
<echo message="Compiling with ${compiler.id}"/>
<delete dir="classes/"/>
<mkdir dir="classes"/>
<javac srcdir="src"
destdir="classes"
compiler="${compiler.id}"
executable="${compiler.exe}"
fork="true"/>
</target>
</project>
Re: Cross-compilation problem
Posted by Christian Schröder <cs...@deriva.de>.
Scot P. Floess wrote:
> Curious, why don't you just use the 1.5 javac but target 1.4? That
> should do what you want... I think all you will need to do is this:
>
> <javac srcdir="src" destdir="classes" source="1.4" target="1.4"/>
The problem is that the 1.5 javac won't complain if I accidently use
functions from the 1.5 api. It will create a class file which *looks*
like 1.4 (as to the class version number), but cannot be executed by a
1.4 jvm.
Try the following example:
public class Test {
public static void main(String[] args) {
String s = "Hello World";
int i = s.codePointAt(0);
}
}
If I compile with "/usr/java/jdk1.5.0/bin/javac -source 1.4 -target 1.4
Test.java" the compiler won't complain. However, if I start this app
with a 1.4 jvm I get the following exception:
Exception in thread "main" java.lang.NoSuchMethodError:
java.lang.String.codePointAt(I)I
at Test.main(Test.java:4)
The 1.4 compiler would have reported the following error:
Test.java:4: cannot resolve symbol
symbol : method codePointAt (int)
location: class java.lang.String
int i = s.codePointAt(0);
^
1 error
That's why I try to use the compiler of the target platform.
Regards,
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT and Consulting Fax: +49 551 489500-91
Hans-Böckler-Straße 2 http://www.deriva.de
D-37079 Göttingen
Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Cross-compilation problem
Posted by "Scot P. Floess" <fl...@mindspring.com>.
Curious, why don't you just use the 1.5 javac but target 1.4? That
should do what you want... I think all you will need to do is this:
<javac srcdir="src" destdir="classes" source="1.4" target="1.4"/>
Christian Schröder wrote:
> Hi list,
> I have some projects that should be compiled with javac 1.4 and some
> that should be compiled with javac 1.5. Since I do not want to change
> my environment between the projects, I have the JAVA_HOME variable set
> to the 1.5 classpath and want ant to use the external 1.4 javac when
> necessary. Unfortunately, I always get an "Error running
> /usr/java/j2sdk1.4.2/bin/javac compiler".
>
> I have been able to create a small example build file to reproduce
> this problem:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <project name="TestProject" default="default" basedir=".">
> <target name="default">
> <javac srcdir="src" destdir="classes" source="1.4" target="1.4"
> fork="yes" executable="/usr/java/j2sdk1.4.2/bin/javac"/>
> </target>
> </project>
>
> With verbose output I get the following stack trace:
>
> /home/chschroe/deriva/projects/DerivaLibLogging/build-tmp.xml:4: Error
> running /usr/java/j2sdk1.4.2/bin/javac compiler
> at
> org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:509)
>
> at
> org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute(JavacExternal.java:61)
>
> at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:997)
> at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:820)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
>
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at org.apache.tools.ant.Target.performTasks(Target.java:385)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>
> at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
> at org.apache.tools.ant.Main.runBuild(Main.java:698)
> at org.apache.tools.ant.Main.startAnt(Main.java:199)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
> Caused by: java.io.IOException: java.io.IOException: Cannot allocate
> memory
> at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
> at java.lang.ProcessImpl.start(ProcessImpl.java:65)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
> at java.lang.Runtime.exec(Runtime.java:591)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec(Execute.java:828)
>
> at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:445)
> at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:459)
> at
> org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:506)
>
> ... 20 more
>
> The machine has several gigs of free memory and this test project is
> really small. So what's the problem?
>
> Some information about my environment:
>
> Apache Ant version 1.7.0 compiled on December 13 2006
> javac 1.5.0_12
> javac 1.4.2_15
>
> Thanks for all help!
> Christian
>
--
Scot P. Floess
27 Lake Royale
Louisburg, NC 27549
252-478-8087 (Home)
919-754-4592 (Work)
Chief Architect JPlate http://sourceforge.net/projects/jplate
Chief Architect JavaPIM http://sourceforge.net/projects/javapim
Architect Keros http://sourceforge.net/projects/keros
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org