Hi Alan
The problem is that in 2.4 the main freetype header is in a top level, then all other headers in a subdirectory. Cmake tries to find both and if it only finds one it fails. This is actually unnecessary as there are macros in freetype (that we use, and are enforced in 2.5) which direct to the subdirectory as needed. In 2.5 the subdirectory structure has changed so cmake cannot find it. I've posted a bug at cmake, but given the lack of response from them re wxWidgets bugs I don't imagine they will be quick to look into it. There may actually be a name clash on windows with a freetype header file too caused by the restructuring.


From: Alan W. Irwin
Sent: ‎26/‎02/‎2014 18:02
To: phil rosenberg
Cc: PLplot development list
Subject: Re: shapelib find module

Hi Phil:

I hope you don't mind that I have redirected this thread back to the list.

On 2014-02-26 04:11-0800 phil rosenberg wrote:

> Hi Alan, that's good regarding the shapelib. No don't worry about
the AGG module.

OK. Thanks for that response to my question.

> Regarding the Freetype module - The CMake provided version
unfortunately doesn't work with freetype 2.5, which is what I am using
at the moment. But it should work with 2.4 so I can downgrade or hack
their version. I will report it to them as a bug, then it's their
problem. I guess we can simply remove the module from plplot.

Yes, that removal has already been done as part of my commit which
makes cmake automatically fall back to the CMake version of that
find module.

Are PATHS values like


in the CMake version the issue?  This general form of PATHS value is
not well documented by CMake, but it is ubiquitous in their official
find modules. From the few sparse references to registry keys within
the documentation, I assume this has something to do with the
registry, and you likely have to add the equivalent for 2.5 to get
everything working for the case when you are relying on the registry.
If so, that is definitely worth a bug report to KitWare.

N.B. There should be no need to downgrade.  You should also have a
pretty straightforward workaround available for that bug which is to
use the appropriate environment variables (such as CMAKE_LIBRARY_PATH)
to guide CMake to find wherever you have installed freetype 2.5.
See the documentation of the CMake find_path command to find
all the relevant environment variables that will affect the
find_path searches in the CMake version of FindFreetype.cmake.

By the way, Wine does have a registry to provide the equivalent
registry functionality that Microsoft Windows has, and it may be a
step above what is possible with the Microsoft Windows registry since
it is an ascii file that can be edited rather than a binary one.  In
any case I have heard bad things about the Microsoft Windows registry
so when I install packages for Wine I usually use idiosyncratic
install prefixes and attempt to avoid the registry as much as possible
just on general principles.  Since bash.exe is available to me from
MSYS and pkg-config.exe available to me from epa_build, I normally
rely on ordinary bash.exe environment variables (along with the CMake
ability to execute pkg-config) to provide the guidance that CMake
needs to find software.  See cmake/epa_build/README.  One bash.exe
"source" command conveniently sets up all required environment
variables using the appropriate file in cmake/epa_build/setup.  Those
files represent my own Linux and Wine platform install idiosyncrasies
so are not directly useful to anyone else, but they do serve as a
template for other epa_build users.  And once Arjen has complete
epa_build success with plplot_lite on MinGW/MSYS/Microsoft Windows
following what I have done on MinGW/MSYS/Wine, I will strongly
encourage him to commit his own setup file(s) to serve as a template
for the MinGW/MSYS/Microsoft Windows platform.

Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).

Linux-powered Science