Kelly O'Hair's Weblog (blogs.sun.com)

« Previous month (Apr 2009) | Main | Next month (Jun 2009) »
pageicon Monday May 11, 2009

Fedora 9 and Mac VMware Fusion 2.0.4

UPDATE: (5/11/2009) Patches for openjdk6 were deleted from this blog, not needed any more if using the latest OpenJDK 6 sources.

Thought I would provide some notes on setting up a Fedora 9 VMware image on my Mac laptop using VMWare Fusion 2.0.4. I used the same steps for both Fedora 9 32bit (i386) and 64bit (x86_64), however I had some trouble with installing x86_64, even seemed to trigger a MacOS panic at one point after doing the yum update, not sure what that was all about, only happened once. This was strictly a local Fedora install, so I didn't need to deal with any of the networking issues of setting up a real physical machine.

I'll try and re-create the order of things as best I can:

  1. Create VMware Virtual Machine from Fedora 9 install iso image. I set it up to have a 20GB disk (You cannot change this disk size afterwards!). I'm using 768Mb RAM (512Mb caused slow builds) and during the install I asked for the "Software Development" packages.

  2. Update your system and make sure you have all you need. Logged in as root: 

    yum install kernel kernel-headers kernel-devel
yum install hg ksh tcsh csh cups cups-devel freetype freetype-devel lesstif-devel
yum groupinstall "X Software Development" "Development Tools" "Java Development"
yum update
    This will take a while. A reboot after you are all done would be a good idea.

  3. Install VMware tools. Once you extract out the VMware tools folder vmware-tools-distrib, once again logged in as root do the following: 

    cd vmware-tools-distro
./vmware-install.pl
    The list of questions to answer is long and convoluted, mostly the default answer works fine, but in some cases it seems to think you are using a remote login and you have to say "yes" to continue the installation.

  4. Mouse problems: For some reason all my single clicks were being treated as double clicks, which drove me nuts. I found this posting which solved the problem, I use option 2 and edited the file /etc/X11/xorg.conf and added the following lines, logged in as root: 

    Section "ServerFlags"
        Option      "AutoAddDevices" "false"
EndSection
    A reboot of your virtual machine is necessary to fix this.

  5. The default limit on file descriptors is very low, to allow for a larger limit the following addition to the file /etc/security/limits.conf will increase that limit, again logged in as root: 

    ################################################
* soft nofile 64000
* hard nofile 64000
################################################
    You need to logout and back in for these new limits to be available.

  6. Recently it was discovered that the upgraded kernel-headers package has trimmed down the files it delivers to /usr/include/linux/ (i.e. dirent.h) and although this doesn't impact OpenJDK building, it could impact builds of parts of the Sun JDK (plugin). So to avoid this missing include file problem, you have to do this last step because the above steps need the latest and matching kernel-headers files. To get the older kernel-headers package run: 

    yum remove kernel-headers glibc-headers
yum install kernel-headers-2.6.25 glibc-headers
    Bugs have been filed on the Sun JDK to see if we can break this dependency on the /usr/include/linux/ files.

That's the basic system setup. In addition I also setup my own home directory with the following so I can build the OpenJDK:

  1. Get webrev tool: 

    mkdir -p ${HOME}/bin
cd ${HOME}/bin
wget http://blogs.sun.com/jcc/resource/webrev
chmod a+x webrev

  2. Get latest ant: 

    mkdir -p ${HOME}/import/ant_home
cd ${HOME}/import/ant_home
wget http://www.apache.org/dist/ant/binaries/apache-ant-1.7.1-bin.tar.gz
tar -xzf apache*.tar.gz
mv apache-ant-1.7.1/* .

  3. Get forest extension: 

    mkdir -p ${HOME}/hgrepos
cd ${HOME}/hgrepos
hg clone http://bitbucket.org/pmezard/hgforest-crew hgforest

  4. Setup your ${HOME}/.hgrc file: 

    cat > ${HOME}/.hgrc <<EOF
[ui]
username = ${USER}
ssh = ssh -C
[trusted]
groups = wheel
[extensions]
fetch=
purge=
mq=
forest=${HOME}/hgrepos/hgforest/forest.py
[defaults]
clone = --pull
fclone = --pull
fetch = -m Merge
ffetch = -m Merge
EOF

  5. Get OpenJDK7 sources (jdk7 build source forest): 

    mkdir -p ${HOME}/hgrepos/jdk7
cd ${HOME}/hgrepos/jdk7
hg fclone http://hg.openjdk.java.net/jdk7/build jdk7-build

  6. Get OpenJDK6 sources (jdk6 master source forest): 

    mkdir -p ${HOME}/hgrepos/jdk6
cd ${HOME}/hgrepos/jdk6
hg fclone http://hg.openjdk.java.net/jdk6/jdk6 jdk6-master

Now to see if I can build both OpenJDK7 and OpenJDK6: 


# To get rid of a few sanity errors
unset JAVA_HOME
LANG=C
export LANG

# My own private copy of ant
ANT_HOME=${HOME}/import/ant_home
export ANT_HOME

# Use the JDK that is part of Fedora 9
ALT_BOOTDIR=/etc/alternatives/java_sdk_1.6.0
export ALT_BOOTDIR

# Add java and ant to the PATH
PATH="${ALT_BOOTDIR}/bin:${ANT_HOME}/bin:/usr/local/bin:/usr/ccs/bin:/usr/ccs/lib:/usr/bin:/bin:/usr/bin/X11:/usr/sbin:/sbin"
export PATH

# Go to the root of the jdk7 source forest
cd ${HOME}/hgrepos/jdk7/jdk7-build

# Build jdk7
#  Don't run javadoc, too slow, needs 1024Mb RAM minimum
make NO_DOCS=true

# Go to the root of the jdk6 source forest
cd ${HOME}/hgrepos/jdk6/jdk6-master

# Build jdk6
#  Don't run javadoc, too slow, needs 1024Mb RAM minimum
make NO_DOCS=true

SUCCESS! They both build.

-kto

Posted at 06:29PM May 11, 2009 by kto in Java  | 

pageicon Thursday May 07, 2009

Painful Ant Bite: A generous CLASSPATH and ant.bat out of hell

Painful ant bytes... ;^) Starting to number them...

  1. When ant runs, it sometimes uses temporary files using the java property java.io.tmpdir as the root of the temporary file area for the system. Unfortunately, the temp file used by ant isn't unique enough to prevent two processes running ant from bumping into each other. We had problems using the same machine to build both Solaris 32bit and Solaris 64bit at the same time. OUCH!

    Jonathan came up with a good solution specific to the JDK in the langtools Makefile that runs ant. He defines the java.io.tmpdir property on the ant command line to be unique to this build area and platform:
    ant -Djava.io.tmpdir='$(ABS_OUTPUTDIR)/build/ant-tmp' ...

    The basic idea is to redefine the java.io.tmpdir (the root of the temporary file area) to something more unique to the circumstances, and ideally in a location that will get cleaned up at the right time.

  2. Had a lovely time (<- sarcasm) tracking down a problem on Windows with JDK ant builds. Apparently on Windows, if you manage to get the ant.bat startup instead of the shell script version of the startup, commas are not allowed on the command line. So you cannot do this:
    ant -Djavac.debuglevel=source,lines,vars OUCH!

    This problem was reported here but nothing was done. Seems like a simple note in the User Manual was a minimum here.

  3. So I downloaded the cpptasks for ant from the ant-contrib site. And it builds from the command line just fine with the latest ant, but it won't build using the ant that comes with NetBeans, and it won't build when loaded into NetBeans. So why is that? The build requires xercesImpl.jar, but the cpptasks build.xml file doesn't explicitly say that, so how did it find it in one case and not in another?

    Turns out that the default behavior for the ant <javac> task is to include all the ant runtime classpath in your java compilation. Yipes! That seems like a horrible default if you ask me, depending on what ant decides to use in its runtime classpath, you get it all? :^( OUCH!

    Seems like every ant installation could potentially behave differently, depending on how ant is configured.

    So I'm thinking I want to change all <javac> uses to <javac includeAntRuntime="false">

    This was also talked about on a JavaLobby forum, with some helpful comments.

-kto

Posted at 11:40AM May 07, 2009 by kto in Java  |  Comments[6]