Alan W. Irwin wrote:
I rarely if ever test the combination of -DBUILD_TEST=ON
-DBUILD_SHARED_LIBS=OFF on Linux, but your error report inspired me to try
the combination, and it appears to work fine.  Of course,
python, java, and octave (which require a shared libraries build) were OFF,
but both the build tree and install tree tests of c, c++, f77, and tcl were
fine.  I also specifically looked at some -dev png results in the install
tree, and they looked fine indicating freetype support is working properly
for Linux for a static PLplot build.
Good, I am glad this is working okay for Linux. My problem with freetype
may be entirely due to the Cygwin installation on my machine.
The freetype issue is weird:
- The executable expects "cygfreetype-6.dll"
- On my system I have "cygfreetype-9.dll"

I have no clue where this discrepancy is coming from - the CMake files
do not contain any reference to any of these libraries.

There is no mention of (the name of the library for
Linux) in our CMake files, either.  Instead, the only name mentioned is
"freetype".  CMake automatically prepends the prefix and appends the suffix
to "freetype" that are appropriate for the library name on the particular
platform (e.g., "lib" and ".so.6.3.5" for my platform).

Since you have some inconsistency in the platform library name derived by
CMake, my best guess is you did not start with an empty build tree so you
have stale build information left over from a time when you had
cygfreetype-6.dll installed. Alternatively, you have both cygfreetype-6.dll
and cygfreetype-9.dll installed, but one or both of them is installed
improperly (i.e., some of the required accompanying files/symlinks are
No, I always start with a completely fresh build directory (well, I throw away
all files in an existing directory and then run CMake, but that should have the
same result).
Anyhow, you have reported before that static libraries work on Cygwin, and
my Linux experiments seem to indicate no new static library problems have
been introduced for our CBS, so that is why I suspect there is some new
problem specific to your system like I have suggested above.

Please let us know the resolution of this newly introduced Cygwin static
library problem once you have fixed it.
Will do. It will require some digging into the freetype installation in my Cygwin
environment - that must be the cause of this strange confusion.

I checked the entire directory structure: there is only one file matching cygfreetype*.dll
and that is cygfreetype-9.dll.
[out of order for clarity]Windows/MSVC 6.0+CVF:
- Building the library is no problem
- Building the Fortran examples fails - because of a conflict with
 (conflicting versions of the runtime libraries - a well-known and
quite annoying

Arjen, I don't have the expertise to interpret this error report.  All I can
tell is you are annoyed by something in the fortran examples build on your
windows platform.  Could you clarify please?  For example, is this a bug we
should fix in our CBS, a windows annoyance we should mention on the wiki
because most window's developers will be unaware of it, or some window's
annoyance that most windows developers will understand so there is no need
to mention it?
Jim already fixed it. I am sorry that some deep personal frustration has crept into
the above ... Let me try to explain:

On Windows compilers incorporate information about the runtime library that
is to be used  in the object files. Different runtime libraries are used for different
global options: debugging, multithreading, ...

When the linker gathers all these object files together, it also reads this information
to get the correct runtime libraries. But if compiler options (especially from different
compilers - in our case the C and the Fortran compiler) cause different runtime libraries
to be specified, there can be a conflict. This frequently leads to error messages
such as "library X: some symbol already defined in library Y".

The annoying part (and that is where my frustration comes from) is that it is often
unclear what you should do about it and sometimes it appears that there is no other
solution than _force_ the linker to produce output.

I will submit (an edited version of) this text to the Wiki, because people may well
run into this.