Skip to end of metadata
Go to start of metadata

Building the BSD port of OpenJDK, Java 1.7 on Max OS X 10.6.4

This content began its life at http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5, but should be annotated and extended as we learn more. See the BSD-Port mailing list for information.


SoyLatte 32-bit Java 1.6 binaries

One can use Landon Fuller's SoyLatte 32-bit Java 1.6 binaries to build the OpenJDK bsd port. After downloading the binaries, copy the whole directory to /usr/local/soylatte16-i386-1.0.3

Test the SoyLatte install:


If you have MacPorts installed:

Otherwise you will need to download the latest version and install it.

Test the mercurial install:

Forest Extension to Mercurial

Note: The Forest extension does not seem to be actively maintained as noted from the ForestExtension wiki page. Please use Patrick Mézard's clone of hgforest instead (just a couple of fixes to Simon's work):

After cloning hgforest-crew add an hgext.forest item with the path to hgforest-crew/forest.py in the extensions section in your ~/.hgrc file.

You will need to create a Mercurial configuration file called .hgrc in your home directory (~/.hgrc). A minimum version requires the following:

If you have MacPorts installed, use:

If you get an error from trying to clone the tree at this point (AttributeError: 'httprepository' object has no attribute 'do_read'), you should edit the forest.py files under /opt and change the occurrences of "do_read" to "_call".

Checkout the code using hg/forest.

Here's what my bsd-port dir looks like:

Build OpenJDK

I added the script build.sh to keep track of the correct build invocation. The version below is adapted from Kurt Millers email here. Edit the paths to fit your dir structure. This script needs to be run with the source command.



  • JiBX was required previously, but is no longer required. If you are building an older version of OpenJDK you will need to download JiBX and add the following to your build script:
  • gcc 4.0 and g++ 4.0 were required for the build. The defaults on Mac OS X 10.6.4 are gcc and g++ 4.2.1.

Build OpenJDK like this:

I have managed to compile the JDK in 64-bit mode on 10.6.4. It is listed as amd64, but it is running on Intel Core Duo. Here is my build script.


The final result:

One person reports: "This takes about 10m on my 2.5 GHz Intel Core 2 Duo MacBook Pro." Please check with the BSD-Port mailing list if you encounter problems.

Error Recovery

Try cleaning if you get errors.

Some errors when compiling are fixed by cleaning. You can temporarily add the clean command to the end of build.sh and source it to clean the build products.

Or you can try this suggestion from Kurt Miller:


If the build fails with the message:

Install the latest version of FreeType .

Additionally, It has been reported:

I am not sure what can be done about this. My build.sh script has "ALT_FREETYPE_HEADERS_PATH=/opt/local/include/freetype2 ALT_FREETYPE_LIB_PATH=/opt/local/lib" and these seem to be where the headers and libraries are located....

X11 is needed for build.

If you have not installed this with Mac OS X, or have deleted it, you need to install it. A copy can be obtained from http://xquartz.macosforge.org/trac/wiki/X112.4.0.

Update the bsd-port directory

If updates have been made to the tree, perhaps to fix a bug, you can update your sources with:

Other Build Failures

Warnings are Errors

Jeff Sinclair noted a specific error which occurs during HotSpot compilation because the gcc.make file has a flag to set WARNINGS as ERRORS. This can be fixed by commenting the line in the gcc.make file located in bsd-port/hotspot/make/bsd/makefiles/gcc.make

Certificates are invalid (cacerts)

If you get an error message like the one below, it is an indication that the /jre/lib/security/cacerts file is invalid, or has no entries.

You can check it with the following:

If there is nothing there, you can use the ALT_CACERTS_FILE= to point to a copy of the cacerts file like the one in SoyLatte.


If the build completes do a simple test by asking the JVM to print its version info. It should look something like this:

Then, see how to switch java versions on Mac OS X.

Using Hudson for Continuous Build.

Hudson will perfectly fit to set a continuous build system. You could find a more complete article with screenshot on my blog

You'll need :

  • an OS/X box, under Snow Leopard, 32 and 64bits mode should works
  • Mercurial with hgforest extension

Hudson jobs.

Defined 2 free-style software project jobs, one for building 32 bits JVM, openjdk-1.7-i586, the other to build 64 bits JVM, openjdk-1.7-x86_64.

Each one will use self sufficient script, these will download soylatte JVMs (i386/amd64) and jaxp, jaf and jaxws2 since these are not available from the url defined in ant build scripts.

Execute shell for openjdk-1.7-i586

Execute shell for openjdk-1.7-x86_64

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 03, 2010

    I found that after building OpenJDK 7 on Mac OS X 10.6.4 (with Java for 10.6 update 3), the JVM would crash with a Trace/BDT trap error whenever AWT or Swing got engaged. The culprit was definitely libfontmanager.dylib, or, more specifically, Apple's version of libfreetype.6.dylib. Using the MacPorts /opt/local version of libfreetype.6.dylib worked around this issue, but I found that unsatisfactory. Some light debugging showed a full stop in __CFInitialize. I found a few comments around the web indicating that this error happens when CoreFoundation is initialized from a thread that is not the main thread: In this case, the UI thread. I recompiled OpenJDK 7 after adding

    to build.sh. This forces the "java" binary to preload CoreFoundation, and in some simple AWT/Swing tests it appears to resolve the issue. Thought you'd like to know.


  2. Nov 03, 2010

    It didn't works for me in 64bits mode with latest trunk

    OS/X 10.6.4 - XCode 3.2.4 (1708) - gcc-4 (gcc version 4.0.1 (Apple Inc. build 5494))

    I fail also when trying to build 32bits VM:

    1. Nov 03, 2010

      I had the same issue. The "offending" line in attachListener.cpp is:

      It appears that UNIT64_FORMAT is defined as "%lu", but uint64_t is defined as "unsigned long long", where the format string then expects "%llu" instead. I confirmed this with a quick hack, changing the line in attachListener.cpp to:

      After this the 64-bit JVM compiled fine on Mac OS X 10.6.4.

      Of course, this is not a proper patch. Instead, the definition of UINT64_FORMAT should be set properly. This seems to have something to do with the header files globalDefinitions.hpp and globalDefinitions_gcc.hpp. In particular, the latter one defines:

      My best guess is that the _LP64 macro is set, but Mac OS X still needs "ll" as its FORMAT64_MODIFIER. This is kind of out of my depth, though, so maybe someone else could comment on this?

    2. Nov 03, 2010

      Also, this is an effect of the "Warnings are Errors" issue described above. Open hotspot/make/bsd/makefiles/gcc.make and comment out the warnings-are-errors line:

      That'll allow the build to finish without any of the other edits I mentioned earlier.


Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.