Opened 10 years ago

Closed 10 years ago

#5 closed task (fixed)

Build langtools

Reported by: dmik Owned by:
Priority: blocker Milestone: Core
Component: general Version:
Severity: Keywords:


Build the langtools component of OpenJDK.

Change History (6)

comment:1 Changed 10 years ago by dmik

This seems to be the easiest part to start with, only one C source and the rest is Java. Note that we use Odin-based JDK 1.5.0 so far.

One problem I found so far is that Ant uses CMD.EXE to start javac.exe when the 'fork' attribute of the <javac> task is set to 'true'. And, by default, Ant passes the system classpath (i.e. the classpath set when starting Ant) to javac.exe as a command line argument. Since this classpath is really long, it somehow screws up CMD.EXE which aborts with the famous SYS0008 error.

This system classpath is not actually necessary for compiling things in our case (it only contains various Ant .jars necessary for Ant itself but not for OpenJDK) and, after reading Ant docs I found that you can avoid adding the system classpath with the 'includeAntRuntime' set to 'no' in <javac> or simply by setting the Java property 'build.sysclasspath' to 'ignore' which has the same effect but on the global scope. This is done in r21 and I can now see that the build of langtools is going on.

comment:2 Changed 10 years ago by dmik

Okay, this doesn't seem to really help: we still hit some command line limitation (via a long list of .java files to compile) -- this time, CMD.EXE simply hangs...

comment:3 Changed 10 years ago by dmik

Ergh, I will have to patch Ant. There is already a generic workaround for the command line length limitation but it is unconditionally turned on when the length exceeds 4K (search for COMMAND_LINE_LIMIT in src\main\org\apache\tools\ant\taskdefs\compilers\DefaultCompilerAdapter?.java) while on OS/2 the limitation is much smaller (1023 chars or so).

comment:4 Changed 10 years ago by dmik

I fixed the CMD.EXE problem in Ant so that <javac> does neither hang nor crash now. Here is a drop-in replacement (README inside):

I also filed a bug in the Apache bug database: Let's hope it will be fixed in the next release as it is trivial.

comment:5 Changed 10 years ago by dmik

The next problem is that mm.mysql-2.0.14-bin.jar in the copy of JRE 1.5.0 I have is corrupt. I will have to find an original JDK 1.5.0_07 distribution from Sun.

comment:6 Changed 10 years ago by dmik

Resolution: fixed
Status: newclosed

That was a false alarm: this .jar was mistakenly located in the JRE directory and is not actually part of it. After deleting it, the build finished successfully.

Note: See TracTickets for help on using tickets.