On 2013-07-24 09:36+0200 Arjen Markus wrote:
> Hi Alan,
>
> I did find the libraries/packages you mentioned. For Qt4 I had to look harder
> than I did before. However, this has let to some issues:
>
> - The Cygwin setup report an error with pango1.0.sh (or something similar).
> - CMake can not find pango, pangoft2 or lasi via pkg-config (tunring off
> PLD_psttf), but a lot of drivers related are now supported.
> - My Qt4 installation appears not to be complete. Will have to look into that
> later.
>
> But more importantly: I get compile errors when building the system. See the
> attached reports. I do not have time to look into this issue, but it seems to
> be connected to the system header files.
Hi Arjen:
It appears you have run out of time so these comments are
for you to look at primarily after your holiday. To keep my replies
in context I will repeat the appropriate part of what you said above
(in a different order).
> - The Cygwin setup report an error with pango1.0.sh (or something similar).
My understanding from lurking on the Cygwin list is that project has
just gone through a new major release with a new setup.exe, new
arrangement of files, etc. So the pango-related setup error you are
currently encountering might be due to mixing old and new components
of Cygwin together. Anyhow, I suggest you reinstall cygwin from
scratch using the latest setup.exe when you get back from your
holiday. If you still have setup.exe errors or warnings at that
stage, I would take those quite seriously and get advice from the
Cygwin list about what to do about those.
> - CMake can not find pango, pangoft2 or lasi via pkg-config (tunring off
> PLD_psttf).
The solution is to build and install libLASi first (which provides the
needed *.pc file). I am pretty sure Werner was able to do that
in the old days with Cygwin, but this step should probably be lower priority
than getting the cairo and qt devices to work.
> - My Qt4 installation appears not to be complete. Will have to look into that
> later.
The Cygwin software distribution follows the Linux convention where
library packages are of two kinds. A development package (including
headers, *.pc files, etc.,) that allows other packages (such as
PLplot) to be built against the library in question. A run-time
library package that just contains the libraries needed at run time.
Normally, the development package depends on the run-time package
(meaning if you install the development package you will also
automatically install the run-time package). For the Qt4 case it
appears to me that you still have to install the development package.
That will include not only the headers, but also the qmake executable
(similar in spirit to pkg-config but quite different in implementation)
which is the primary means that CMake uses to figure out the compile
and link options needed for application/libraries (e.g., the PLplot qt
device driver) that
link against Qt4.
> [...]a lot of drivers related are now supported.
> [...]
> But more importantly: I get compile errors when building the system. See the
> attached reports. I do not have time to look into this issue, but it seems to
> be connected to the system header files.
It is a nice breakthrough that you are now at the point where an
attempt is being made to build the cairo device driver.
Once you have a clean install of Cygwin, you might find that the
windows.h header issues you are encountering with that build
just disappear. But assuming they will still occur, then
the overview is that CMake executes pkg-config to obtain the
correct compile and link options for applications/libraries that are using
pango/cairo, and it appears that information is incorrect for Cygwin
because of the header issues you are encountering. A couple of
explanations spring to mind.
(1) CMake does not make the correct pkg-config call for the Cygwin
platform. If you look at the pkg-config man page, there are several
overall Windows-only options such as
--msvc-syntax
This option is available only on Windows. It causes pkg-config
to output -l and -L flags in the form recognized by the Mi‐
crosoft Visual C++ command-line compiler, cl. Specifically,
instead of -Lx:/some/path it prints /libpath:x/some/path, and
instead of -lfoo it prints foo.lib. Note that the --libs output
consists of flags for the linker, and should be placed on
the cl command line after a /link switch.
It is possible, for example, that CMake uses such options in error for
Cygwin (which I understand tries to emulate Unix as much as possible
so --msvc-syntax is unlikely to be appropriate.)
(2) There could be bugs in the *.pc files (e.g., pangocairo.pc) that contain
the information
that pkg-config delivers.
The way to distinguish between these two possibilities is to run the
exact compile command by hand that causes the errors. (You can find
that command by looking at make.out). Of course, that will just
repeat the header errors, but you should compare the compiler options
used by that command with the corresponding output from running
pkg-config by hand (say with and without --msvc-syntax or other
Windows flags). For example,
pkg-config --cflags pangocairo
or
pkg-config --msvc-syntax --cflags pangocairo
By such comparisons you might be able to decide between the two
possibilities above. For example, if you can get the right set of
compile flags to eliminate the error by running pkg-config by hand
with appropriate overall options, then it appears that CMake is not
using the right set of overall pkg-config options for the Cygwin
platform, and this is an issue to take to the CMake mailing list. On
the other hand, if you can find no way that pkg-config generates
compile options by hand that can be used to correct the compile
errors, then you have the basis of a simple test case not involving
cmake (an important simplification!) that you can take to the Cygwin
mailing list.
I also have one additional comment concerning the permissions issues
that you have had to deal with. Again, I would simplify the case as
much as possible. For example, does "cmake -P test.cmake" where
test.cmake has a fragment of CMake logic to configure a file generate
the issue? Same question for "cmake -E copy ..." and "cp ...".
Anyhow, once you have established the simplest test case from the
above list, then I would take that case to the Cygwin list for their
comments. My guess is the solution will be to configure your Cygwin
user account so that correct permissions are used for generated files.
RedHat (the company behind Cygwin) is quite serious about security so
it wouldn't surprise me in the least if generated files all have zero
permissions by default unless you reconfigure your Cygwin user
account.
In sum, I think you are making good progress. So with that in mind,
have fun on your holiday, and afterwards come back fresh to start
exploring this Cygwin terra incognita again with the help of this
e-mail. :-)
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
__________________________
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
