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 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
missing).
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
MSVCRTD.DLL
(conflicting versions of the runtime libraries - a well-known and
quite annoying
problem)
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.
Regards,
Arjen
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
