Re: [Plplot-general] Including cairo driver

[Walt B. <wal...@gm...>]

OK. I think I have it.
Using your latest instructions, I get cairo and wingcc drivers.

I didn't do anything about -lm to get things to work ???
When it worked before, I had to delete -lintl ???

Lots of names changed by having to drop the "d" at the end.
I assume I was doing a double precision build.

I nominate you for Amazing Remote Debugger. (Maybe I
could do some of that with a Fortran program, but not this
kind of stuff.)

Thanks again for all the help. Plplot is going into the next
Fortran Tools, but I don't yet much info about using it with
cairo. I must suspend the fun stuff as I have a little job to
"modernize" 1,000,000 lines of Fortran code.

I still would welcome comments on that attempt to use
Plplot.


On Wed, May 14, 2014 at 8:24 PM, Alan W. Irwin <ir...@be...>wrote:

> On 2014-05-14 16:37-0700 Walt Brainerd wrote:
>
>  I seem to be going backwards.
>> 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
>> keep getting the "not found" messages.
>>
>
> Hi Walt:
>
> 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
> format.)
>
> 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.
>
>
>  and now I can't
>> even get pkg-config to work from the command.
>>
>> C:\walt\Software\Plplot\BUILD>dir C:\FortranTools\gtk\lib\
>> pkgconfig\cairo.pc
>> 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
>>
>> C:\walt\Software\Plplot\BUILD>pkg-config cairo
>>
>
> That is not the correct way to get library and cflags information
> out of pkg-config.  Run
>
> pkg-config --help
>
> 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
>
> __________________________
> 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
> __________________________
>



-- 
Walt Brainerd