RFR(M): 8057538: Build the freetype library during configure on Windows

Volker Simonis volker.simonis at gmail.com
Thu Sep 4 16:59:50 UTC 2014


could you please have a look at the following change which makes it
possible to build the freetype libraries during the configure step
from the plain freetype sources on Windows:


The fact that there are no standard binary packages of freetype
available on windows is one of the few remaining annoyances when
building the OpenJDK on Windows.

It turns out however, that it is relatively simply and needs just a
few seconds to build the required libraries from the freetype source
ball during the configure process. The only extra dependency which is
required is 'msbuild.exe' which comes with the .NET 4.0 installation
and as far as I could see, probably most of the Windows boxes will
have that anyway.

This change will introduce a new configure option
"--with-freetype-src" which builds the required freetype libraries
into <freetype_src>/lib[32|64] and sets "--with-freetype-lib" and
"--with-freetype-include" automatically.

Later builds can than simple use
"--with-freetype-lib=<freetype_src>/lib[32|64]" and

If this new option is used, the build results will be available in

Notice that I intentionally build the libraries into the freetype
source directory. On the one hand it's considered bad style to pollute
the source directory, on the other hand, we'll only have to do this
two times (once for a 32- and once for a 64-bit build) and use the
created libraries for all other builds later on.

I've tested this on a 64-bit Windows 7 box with both Cygwin and
MingGW/MSYS building both, 32- and 64-bit versions of the OpenJDK.
However I only tested with a vanilla SDK 7.1 installation. I think the
build should also work with a VS2010 installation, but I'd need
sombody to test it. If it should not work, I think it can be easily
fixed in common/autoconf/libraries.m4 by inserting the corresponding
toolset identifiers as described by this comment:

          # The original freetype project file is for VS 2010 (i.e.
'v100'), so we have to adapt the toolset if building with the SDK
          # TODO: we may also have to set the toolset to 'v110' or
'v120' if building with VS 2012 or VS2013 respectively
          # TODO: find a better (more reliable) test for the actual,
active toolset
          if $ECHO "$VS_PATH" | grep -q 'SDKs'; then

Thank you and best regards,

More information about the build-dev mailing list