On 2014-05-14 16:37-0700 Walt Brainerd wrote:
I seem to be going backwards.keep getting the "not found" messages.
I downloaded the trunk and executed cmake with
what I think is all of your requested options.
I get neither cairo nor wingcc now. Don't know why I
Don't get discouraged. You are actually moving forward. :-)
For example, I am pretty good at remote debugging (which we must
necessarily do in this case since I do not confirm the issue you are
finding on my own Windows platform, and I don't expect you to
completely understand the PLplot build system logic at first glance). I
actually think we are pretty close to a solution, see below.
I see nothing wrong with your cmake options.
There was enough information in the cmake output so that I realized
you are failing to find one particular library. I am virtually
positive that library (not only required for wingcc but also our cairo
device driver on Windows) is gdi32, but the warning diagnositics
provided by our build system are not currently detailed enough to
confirm that. So I have (as of revision 13120) updated those
diagnostics to be much more verbose when something is going wrong with
pkg-config so the library that is not found can at least be figured
out from those diagnostic messages.
So for the next iteration do an svn update first to get access to the
better warnings. Also, if you are not following this good advice
already, please delete your old build tree and start over with an
empty build tree (so your build is not clobbered by bad stale results
that are cached from your previous failing attempts).
Note, I am pretty sure you will not have further trouble if you
provide CMake the obvious guidance it needs to find the gdi32 library.
Also, I must say that getting that guidance right was the most
difficult aspect of my own MinGW/Wine test case. In my case with
MinGW-4.7.2 the location of that library was in a subdirectory of the
MinGW install, i.e., z:/home/wine/newstart/MinGW-4.7.2/lib/libgdi32.a.
(and if I specified an alternative Windows system location that
appeared to contain a dll related to gdi32, that did not work in the
slightest with a run-time error message concerning a wrong library
So it was essential for me to set one component of the environment
variable CMAKE_LIBRARY_PATH to z:/home/wine/newstart/MinGW-4.7.2/lib
so that CMake would know to look in that directory for the gdi32
library that our build system needs. I am pretty sure setting the
CMAKE_LIBRARY_PATH environment variable equivalently (using the
appropriate install prefix for wherever you installed MinGW) will
"just work" for you.
However, if not, I am game for at least one more iteration of remote
debugging if you continue to provide me with your cmake invocation,
cmake output, _and_ also add the relevant environment variables (I
have mentioned the complete list of those before in this thread) and the
CMakeCache.txt file in the top of the build tree that is generated by
the cmake command. And if cmake is okay, but the further build is
not, then you should supply the additional VERBOSE=1 output from
that build.That is not the correct way to get library and cflags information
and now I can't
even get pkg-config to work from the command.
Volume in drive C has no label.
Volume Serial Number is BADA-0412
Directory of C:\FortranTools\gtk\lib\pkgconfig
09/21/2013 06:46 AM 409 cairo.pc
1 File(s) 409 bytes
0 Dir(s) 35,996,807,168 bytes free
out of pkg-config. Run
to see what is possible. But to get all the library flags
for the cairo library you should invoke it as
pkg-config --libs cairo
and similarly the compile flags are determined using
pkg-config --cflags cairo
So make sure those commands give you sensible looking results which
tests that your PATH and possibly (if needed) your PKG_CONFIG_PATH
environment variables are set up properly to find cairo. Note, this
is only a test and not part of the build since cmake calls pkg-config
internally using the PATH and PKG_CONFIG_PATH environment variables
you have set (and then transforms the results afterwards into the
form that is needed including dropping -lm for the Windows case).
Please see request above for all the information that is required
including all relevant environment variables if you have any troubles
for this iteration. But I predict if there is a problem, then as soon
as you collect the requested information for me, you will probably
immediately understand and fix the problem with your setup. :-)
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).