Alan W. Irwin wrote:
Good, I am glad this is working okay for Linux. My problem with freetype
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.
may be entirely due to the Cygwin installation on my machine.
No, I always start with a completely fresh build directory (well, I
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 libfreetype.so.6.3.5 (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
all files in an existing directory and then run CMake, but that should
Will do. It will require some digging into the freetype installation in
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.
environment - that must be the cause of this strange confusion.
I checked the entire directory structure: there is only one file
and that is cygfreetype-9.dll.
Jim already fixed it. I am sorry that some deep personal frustration
has crept into
[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
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?
the above ... Let me try to explain:
On Windows compilers incorporate information about the runtime library
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
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
to be specified, there can be a conflict. This frequently leads to
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.