Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2013-07-09 21:49:25
|
I am pretty good (if I do say so myself) at making wholesale changes
to our source code using the killer combination of find, grep, and sed.
So I volunteered to do such needed changes for the WIN32 case for Arjen,
and revision 12411 is the result. The wholesale changes were
WIN32 AND NOT CYGWIN ==> WIN32_AND_NOT_CYGWIN
WIN32 ==> WIN32_OR_CYGWIN
In addition our top-level CMakeLists.txt file was changed
to
1. Force the modern CMake interpretation (where WIN32 is false on
Cygwin platforms)
2. define the variables WIN32_AND_NOT_CYGWIN and WIN32_OR_CYGWIN
>From now on the variable WIN32 should not be used in our build system
code except under extraordinary circumstances which are currently.
software@raven> find -name CMakeLists.txt -o -name "*.cmake" | \
grep -v build_projects |xargs grep '[^_]WIN32[^_]'
./cmake/modules/summary.cmake:WIN32: ${WIN32}
./examples/c++/CMakeLists.txt: add_executable(wxPLplotDemo WIN32
wxPLplotDemo.cpp)
./CMakeLists.txt:# Force CMake to _NOT_ define 'WIN32' on Cygwin
./CMakeLists.txt:set(WIN32_AND_NOT_CYGWIN ${WIN32})
./CMakeLists.txt:if(WIN32 OR CYGWIN)
./CMakeLists.txt:else(WIN32 OR CYGWIN)
./CMakeLists.txt:endif(WIN32 OR CYGWIN)
./CMakeLists.txt:if(BUILD_SHARED_LIBS AND WIN32)
./CMakeLists.txt:endif(BUILD_SHARED_LIBS AND WIN32)
./CMakeLists.txt:if(WIN32)
./CMakeLists.txt:else(WIN32)
./CMakeLists.txt:endif(WIN32)
Instead, the variables WIN32_AND_NOT_CYGWIN, WIN32_OR_CYGWIN, or
CYGWIN should be used as appropriate.
Arjen, there are no guarantees with such wholesale changes, but please
give revision 12411 a try on your Cygwin platform and make further
build-system changes as required for that platform using the CMake
variables WIN32_AND_NOT_CYGWIN, WIN32_OR_CYGWIN, or CYGWIN.
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
__________________________
|
|
From: Arjen M. <arj...@de...> - 2013-07-10 08:08:20
|
Hi Alan,
thanks for this - I will go and test it the coming days.
Regards,
Arjen
On Tue, 9 Jul 2013 14:49:16 -0700 (PDT)
"Alan W. Irwin" <ir...@be...> wrote:
> I am pretty good (if I do say so myself) at making
>wholesale changes
> to our source code using the killer combination of find,
>grep, and sed.
> So I volunteered to do such needed changes for the WIN32
>case for Arjen,
> and revision 12411 is the result. The wholesale changes
>were
>
> WIN32 AND NOT CYGWIN ==> WIN32_AND_NOT_CYGWIN
> WIN32 ==> WIN32_OR_CYGWIN
>
> In addition our top-level CMakeLists.txt file was
>changed
> to
>
> 1. Force the modern CMake interpretation (where WIN32 is
>false on
> Cygwin platforms)
>
> 2. define the variables WIN32_AND_NOT_CYGWIN and
>WIN32_OR_CYGWIN
>
>From now on the variable WIN32 should not be used in our
>build system
> code except under extraordinary circumstances which are
>currently.
>
> software@raven> find -name CMakeLists.txt -o -name
>"*.cmake" | \
> grep -v build_projects |xargs grep '[^_]WIN32[^_]'
> ./cmake/modules/summary.cmake:WIN32:
> ${WIN32}
> ./examples/c++/CMakeLists.txt:
> add_executable(wxPLplotDemo WIN32
> wxPLplotDemo.cpp)
> ./CMakeLists.txt:# Force CMake to _NOT_ define 'WIN32'
>on Cygwin
> ./CMakeLists.txt:set(WIN32_AND_NOT_CYGWIN ${WIN32})
> ./CMakeLists.txt:if(WIN32 OR CYGWIN)
> ./CMakeLists.txt:else(WIN32 OR CYGWIN)
> ./CMakeLists.txt:endif(WIN32 OR CYGWIN)
> ./CMakeLists.txt:if(BUILD_SHARED_LIBS AND WIN32)
> ./CMakeLists.txt:endif(BUILD_SHARED_LIBS AND WIN32)
> ./CMakeLists.txt:if(WIN32)
> ./CMakeLists.txt:else(WIN32)
> ./CMakeLists.txt:endif(WIN32)
>
> Instead, the variables WIN32_AND_NOT_CYGWIN,
>WIN32_OR_CYGWIN, or
> CYGWIN should be used as appropriate.
>
> Arjen, there are no guarantees with such wholesale
>changes, but please
> give revision 12411 a try on your Cygwin platform and
>make further
> build-system changes as required for that platform using
>the CMake
> variables WIN32_AND_NOT_CYGWIN, WIN32_OR_CYGWIN, or
>CYGWIN.
>
> 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
> __________________________
>
>
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
|
|
From: Arjen M. <arj...@de...> - 2013-07-10 11:15:34
|
Hi Alan, I have tried to build PLplot using this latest revision under Cygwin, but I run into the problem that apparently USE_RPATH is set now, so that the DLLs are not properly installed as under Windows in the directory "dll". I can not find where this variable is set. Do you know where it is coming from? Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-10 15:59:23
|
On 2013-07-09 14:49-0700 Alan W. Irwin wrote:
> From now on the variable WIN32 should not be used in our build system
> code except under extraordinary circumstances which are currently.
>
> software@raven> find -name CMakeLists.txt -o -name "*.cmake" | \
> grep -v build_projects |xargs grep '[^_]WIN32[^_]'
> ./cmake/modules/summary.cmake:WIN32: ${WIN32}
> ./examples/c++/CMakeLists.txt: add_executable(wxPLplotDemo WIN32
> wxPLplotDemo.cpp)
> ./CMakeLists.txt:# Force CMake to _NOT_ define 'WIN32' on Cygwin
> ./CMakeLists.txt:set(WIN32_AND_NOT_CYGWIN ${WIN32})
> ./CMakeLists.txt:if(WIN32 OR CYGWIN)
> ./CMakeLists.txt:else(WIN32 OR CYGWIN)
> ./CMakeLists.txt:endif(WIN32 OR CYGWIN)
> ./CMakeLists.txt:if(BUILD_SHARED_LIBS AND WIN32)
> ./CMakeLists.txt:endif(BUILD_SHARED_LIBS AND WIN32)
> ./CMakeLists.txt:if(WIN32)
> ./CMakeLists.txt:else(WIN32)
> ./CMakeLists.txt:endif(WIN32)
>
> Instead, the variables WIN32_AND_NOT_CYGWIN, WIN32_OR_CYGWIN, or
> CYGWIN should be used as appropriate.
Actually, the last 5 lines of the above listing are logically correct
(since WIN32 is now equivalent to WIN32_AND_NOT_CYGWIN), but I have
changed them as of revision 12413 to WIN32_AND_NOT_CYGWIN to reduce
ambiguity.
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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2013-07-10 16:57:05
|
On 2013-07-10 13:15+0200 Arjen Markus wrote:
> Hi Alan,
>
> I have tried to build PLplot using this latest revision
> under Cygwin, but I run into the problem that apparently
> USE_RPATH is set now, so that the DLLs are not properly
> installed as under Windows in the directory "dll".
>
> I can not find where this variable is set. Do you know
> where it is coming from?
cmake/modules/rpath.cmake.
But I don't think that matters because I am virtually positive USE_RPATH
is not the issue. After my most recent change to reduce ambiguity
(but effectively this was not a logic change) the relevant code
concerning dll looks like this:
if(BUILD_SHARED_LIBS AND WIN32_AND_NOT_CYGWIN)
set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32_AND_NOT_CYGWIN)
That code started out as ... AND WIN32 AND NOT CYGWIN
You recently changed it to ... AND WIN32 (which is logically equivalent
for modern CMake/Cygwin where WIN32 true implies CYGWIN is false),
and I have now changed that back to
... AND WIN32_AND_NOT_CYGWIN (again logically equivalent to all the
rest) to reduce ambiguity about what is meant.
I then looked at other places in our code where /dll is mentioned.
software@raven> find -name CMakeLists.txt -o -name "*.cmake" \
|grep -v build_projects |xargs egrep '/dll([^a-zA-Z]|$)'
./bindings/ada/CMakeLists.txt: WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/dll
./drivers/CMakeLists.txt: PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/dll
./examples/python/CMakeLists.txt: set(python_location4 ${CMAKE_BINARY_DIR}/dll)
./examples/lua/CMakeLists.txt: set(lua_lib_location ${CMAKE_BINARY_DIR}/dll)
./CMakeLists.txt: set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
Some were inside WIN32_AND_NOT_CYGWIN logic blocks and some were
inside WIN32_OR_CYGWIN logic blocks. As of revision 12414 I got rid of that
inconsistency by changing all references to dll to be inside WIN32_AND_NOT_CYGWIN
logic blocks.
I am pretty sure that will work since historically CYGWIN never needed
the dll workaround that is required for all other Windows platforms.
But to check that please systematically run the following test steps
and whether you get success or not please send me the results I
request below.
1. Run cmake with -DBUILD_TEST=ON and do not say anything about
USE_RPATH since the default should be fine. No dll subdirectory should
be created. Please collect the cmake
output in cmake.out and also the CMake cache file as per my usual
request.
2. Run
make VERBOSE=1 test_noninteractive >& test_noninteractive.out
3. If (2) works, run
make VERBOSE=1 install >& install.out
However far you get with those steps, please send me a tarball with
all the *.out files and the CMake cache file.
Also, on Cygwin (if you install the relevant package) you should
have access to the "ldd" command. Please run that on some of
the libraries created as part of step 2 and send me those results as
well.
As a comparison here is one typical result on Linux:
software@raven> cd build_dir
software@raven> ldd -r src/libplplotd.so
linux-vdso.so.1 => (0x00007fffd8917000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f80032d3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8003050000)
libcsirocsa.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0 (0x00007f8002e46000)
libcsironn.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0 (0x00007f8002c3f000)
libqsastime.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0 (0x00007f8002a39000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f800279a000)
libshp.so.1 => /home/software/shapelib/install/lib/libshp.so.1 (0x00007f8002589000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f80021fe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8001ffa000)
libqhull.so.5 => /home/software/qhull/install/lib/libqhull.so.5 (0x00007f8001d96000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8001b7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f800377a000)
Note, these results show there are no missing libraries, and all the
ones that are built in the build tree are found there rather than some
other inappropriate place. Furthermore, the -r option checks further
to make sure all symbols get defined by the libraries that are found.
Note, that rpath (which is used by fundamental CMake default for the
build tree for platforms like Linux and Cygwin that support rpath)
allows those build-tree libraries to be found. So if rpath is working
on Cygwin (like it has in the past for your builds) you should get
similar results to these, and all other results above should just
work.
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
__________________________
|
|
From: Arjen M. <arj...@de...> - 2013-07-11 04:47:59
|
Hi Alan, On Wed, 10 Jul 2013 09:56:57 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > On 2013-07-10 13:15+0200 Arjen Markus wrote: > >> Hi Alan, >> >> I have tried to build PLplot using this latest revision >> under Cygwin, but I run into the problem that apparently >> USE_RPATH is set now, so that the DLLs are not properly >> installed as under Windows in the directory "dll". >> >> I can not find where this variable is set. Do you know >> where it is coming from? > > cmake/modules/rpath.cmake. > Ah, that was stupid - I misinterpreted the logic. > But I don't think that matters because I am virtually >positive USE_RPATH > is not the issue. After my most recent change to reduce >ambiguity > (but effectively this was not a logic change) the >relevant code > concerning dll looks like this: > ... Well, that has not been my experience, or better, by putting the DLLs into the dll subdirectory the test-drv-info program was able to start properly and do its job. Another thing I have some doubts about is that a successful "-rpath build" will lock the DLLs into a fixed set of directories which interfers with a later installation. Anyway, I will go and test this new logic in accordance with your receipe. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-11 07:07:39
|
On 2013-07-11 06:47+0200 Arjen Markus wrote: > On Wed, 10 Jul 2013 09:56:57 -0700 (PDT) > "Alan W. Irwin" <ir...@be...> wrote: >> But I don't think that matters because I am virtually positive USE_RPATH >> is not the issue. After my most recent change to reduce ambiguity >> (but effectively this was not a logic change) the relevant code >> concerning dll looks like this: >> > ... > > Well, that has not been my experience, or better, by > putting the DLLs into the dll subdirectory the test-drv-info > program was able to start properly and do its job. You can use the ldd programme to confirm the driver dll's find everything properly. The result is good on Linux both for the build tree and install tree (thanks to our rpath configuration). Also, the test-drv-info results are good in the build tree on Linux. So in theory you should get as good Cygwin linking results as we do in the Linux case. But please confirm that by trying ldd on all dll's both in the build tree and also in the install tree. > Another thing I have some doubts about is that a > successful "-rpath build" will lock the DLLs into a > fixed set of directories which interfers with a later > installation. By default, CMake sets rpath appropriately for all build-tree dll's, but does not set rpath at all for install-tree dll's (which means the dll's have to be relinked on installation to remove rpath for that default case). We leave that default behaviour as is for the build tree, but via USE_RPATH we modify that default behaviour for the install tree by setting the INSTALL_RPATH target property for all dll's. That does not affect the build-tree linking at all, but upon installation instead of the relinking removing rpath (by default), it changes it to the correct install location. So there is no locking of the DLL linking. There is obviously a lot going on behind the scenes with regard to linking, and I hope I have explained it in an understandable way, but the net result is all is well for Linux (and historically for Cygwin) both in the build tree and also in the install tree (thanks to the relinking that occurs for all installed dll's). > > Anyway, I will go and test this new logic in accordance > with your receipe. I look forward to those results. Best wishes, 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 __________________________ |
|
From: Arjen M. <arj...@de...> - 2013-07-12 07:53:47
|
Hi Alan,
below is the output from CMake and make on Cygwin.
While CMake was successful, make failed due to problems
with test-drv-info.exe. There was indeed no dll
subdirectory
created.
If I run ldd on this executable file, the result is:
test-drv-info.exe:
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll
(0x774d0000)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll
(0x75930000)
KERNELBASE.dll =>
/cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75450000)
SYSFER.DLL => /cygdrive/c/Windows/SysWOW64/SYSFER.DLL
(0x74e20000)
cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
cygltdl-7.dll => /usr/bin/cygltdl-7.dll (0x6f700000)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6fcb0000)
For the drivers themselves, for example xfig.dll, a
strange entry pops up:
xfig.dll:
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll
(0x774d0000)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll
(0x75930000)
KERNELBASE.dll =>
/cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75450000)
SYSFER.DLL => /cygdrive/c/Windows/SysWOW64/SYSFER.DLL
(0x74e20000)
??? => ??? (0x63100000)
This is also the case for the PLplot library itself:
cygplplotd-11.dll:
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll
(0x774d0000)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll
(0x75930000)
KERNELBASE.dll =>
/cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75450000)
SYSFER.DLL => /cygdrive/c/Windows/SysWOW64/SYSFER.DLL
(0x74e20000)
??? => ??? (0x6f900000)
When I put the relevant DLLs in the PATH, nothing changes:
cygplplotd-11.dll with relevant DLLs in PATH:
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll
(0x774d0000)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll
(0x75930000)
KERNELBASE.dll =>
/cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x75450000)
SYSFER.DLL => /cygdrive/c/Windows/SysWOW64/SYSFER.DLL
(0x74e20000)
??? => ??? (0x6f900000)
I can inspect the DLL via a hex viewer and then I see a
number of additional dependencies that ldd does not
report.
My conclusion therefore is still that -rpath does not
work on Cygwin, I am afraid.
Regards,
Arjen
----
CMake output
------------
-- The C compiler identification is GNU 4.5.3
-- Check for working C compiler: /usr/bin/gcc.exe
-- Check for working C compiler: /usr/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CMake version = 2.8.9
-- CMAKE_SYSTEM_NAME = CYGWIN
-- SH_EXECUTABLE = /usr/bin/bash.exe
-- Checking whether system has ANSI C header files
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h -
found
-- Performing Test memchrExists
-- Performing Test memchrExists - Success
-- Performing Test freeExists
-- Performing Test freeExists - Success
-- Check for whether ctype.h macros work on characters
with the
high bit set.
-- High-bit characters - work
-- ANSI C header files - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include file termios.h
-- Looking for include file termios.h - found
-- Looking for include file stdint.h
-- Looking for include file stdint.h - found
-- Looking for crt_externs.h
-- Looking for crt_externs.h - not found
-- Performing Test HAVE_SYS_WAIT_H
-- Performing Test HAVE_SYS_WAIT_H - Success
-- Looking for DIR in sys/types.h;dirent.h
-- Looking for DIR in sys/types.h;dirent.h - found
-- Check for signal return type in <signal.h>
-- Check for signal handler return type type void - found
-- Looking for popen
-- Looking for popen - found
-- Looking for usleep
-- Looking for usleep - found
-- Looking for mkstemp
-- Looking for mkstemp - found
-- Looking for unlink
-- Looking for unlink - found
-- Looking for _NSGetArgc
-- Looking for _NSGetArgc - not found
-- Looking for isfinite
-- Looking for isfinite - found
-- Looking for finite
-- Looking for finite - found
-- Looking for isnan
-- Looking for isnan - found
-- Looking for isinf
-- Looking for isinf - found
-- Looking for snprintf
-- Looking for snprintf - found
-- SWIG was not found. Please specify Swig executable
location
-- Found Perl: /usr/bin/perl.exe (found version "5.14.2")
-- WARNING: Perl module XML::DOM not found
-- Could NOT find PkgConfig (missing:
PKG_CONFIG_EXECUTABLE)
-- Looking for pkg-config - not found
-- WARNING: Makefile+pkg-config version of examples build
in the install tree will not work.
-- X11_FOUND = 0
-- X11_INCLUDE_DIR =
-- X11_COMPILE_FLAGS =
-- X11_LIBRARIES =
-- WARNING: SHAPELIB not found. Setting HAVE_SHAPELIB to
OFF.
-- CMAKE_PLATFORM_INFO_DIR =
/cygdrive/d/plplot-svn/build-cygwin-dll/CMakeFiles
-- The C compiler identification is GNU 4.5.3
-- Check for working C compiler: /usr/bin/gcc.exe
-- Check for working C compiler: /usr/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
--
'CMAKE_PLATFORM_INFO_DIR=/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/CXX/CMakeFiles'
-- CMAKE_GENERATOR = Unix Makefiles
-- The CXX compiler identification is GNU 4.5.3
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to:
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/CXX
-- The CXX compiler identification is GNU 4.5.3
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for using namespace support
-- Check for using namespace - found
-- Looking for C++ include cmath
-- Looking for C++ include cmath - found
-- Check for broken isnan support in <cmath>
-- Check for isnan in <cmath> - found
-- Check for using stdint.h with CXX compiler
-- Check for using stdint.h with CXX compiler - ok
-- The C compiler identification is GNU 4.5.3
-- Check for working C compiler: /usr/bin/gcc.exe
-- Check for working C compiler: /usr/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
--
'CMAKE_PLATFORM_INFO_DIR=/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Fortran/CMakeFiles'
-- CMAKE_GENERATOR = Unix Makefiles
-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler:
/usr/bin/gfortran.exe
-- Check for working Fortran compiler:
/usr/bin/gfortran.exe -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran.exe supports Fortran
90
-- Checking whether /usr/bin/gfortran.exe supports Fortran
90 -- yes
-- Configuring done
-- Generating done
-- Build files have been written to:
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Fortran
-- The Fortran compiler identification is GNU
-- Check for working Fortran compiler:
/usr/bin/gfortran.exe
-- Check for working Fortran compiler:
/usr/bin/gfortran.exe -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran.exe supports Fortran
90
-- Checking whether /usr/bin/gfortran.exe supports Fortran
90 -- yes
-- Check for f77 command line support
-- Check for f77 command line support - found
-- Check if isnan function is available in fortran
-- Check for isnan in fortran - not found
-- NOTICE: Found: /usr/bin/gfortran.exe
-- WARNING: swig not found. Disabling java bindings
-- WARNING: swig not found. Disabling Python bindings
-- WARNING: swig not found. Disabling Octave bindings
-- Looking for include paths and libraries for Tcl/Tk
-- AM: start --
-- Found Tclsh: /bin/tclsh (found version "8.5")
-- AM: after INCLUDEs --
-- AM: parent --
-- AM: /usr/include
-- AM:
/include;/include;;;//include;//include;/usr/include/tcl;/usr/include/tcl;/usr/include/tcl8.6;/usr/include/tcl8.5;/usr/include/tcl8.4;/usr/include/tcl8.3;/usr/include/tcl8.2;/usr/include/tcl8.0
-- Found TCL: /usr/lib/libtcl.dll.a
-- Found TCLTK: /usr/lib/libtcl.dll.a
-- Found TK: /usr/lib/libtk.dll.a
-- Looking for include paths and libraries for Tcl/Tk -
found
-- Looking for tclsh
-- Looking for tclsh - found
-- TCL_TCLSH = /bin/tclsh
-- TCL_INCLUDE_PATH = /usr/include
-- TCL_LIBRARY = /usr/lib/libtcl.dll.a
-- Itcl not available or not compatible with current Tcl
shell
-- WARNING: X11 not found, disabling Tk interface code
-- WARNING: Because Tk is disabled must disable incr Tk as
well
-- The C compiler identification is GNU 4.5.3
-- Check for working C compiler: /usr/bin/gcc.exe
-- Check for working C compiler: /usr/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
--
'CMAKE_PLATFORM_INFO_DIR=/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles'
-- CMAKE_GENERATOR = Unix Makefiles
-- Check for working Ada builder:
GNAT_EXECUTABLE_BUILDER-NOTFOUND
CMake Error at
/cygdrive/d/plplot-svn/plplot/cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake:48
(MESSAGE):
The Ada builder "GNAT_EXECUTABLE_BUILDER-NOTFOUND" is
not able to compile,
bind, and link a simple test program.
It fails with the following output:
Change Dir:
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make.exe
/usr/bin/cmake.exe
-H/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
-B/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake.exe -E cmake_progress_start
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp/CMakeFiles
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp/CMakeFiles/progress.marks
/usr/bin/make -f CMakeFiles/Makefile2 all
make[1]: Entering directory
`/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp'
/usr/bin/make -f
CMakeFiles/testadacompiler.dir/build.make
CMakeFiles/testadacompiler.dir/depend
make[2]: Entering directory
`/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp'
cd
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
&& /usr/bin/cmake.exe -E cmake_depends "Unix Makefiles"
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp/CMakeFiles/testadacompiler.dir/DependInfo.cmake
Scanning dependencies of target testadacompiler
make[2]: Leaving directory
`/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp'
/usr/bin/make -f
CMakeFiles/testadacompiler.dir/build.make
CMakeFiles/testadacompiler.dir/build
make[2]: Entering directory
`/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp'
/usr/bin/cmake.exe -E cmake_progress_report
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp/CMakeFiles
1
[100%] Building Ada object
CMakeFiles/testadacompiler.dir/testadacompiler.o
/usr/bin/gcc.exe -c
/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp/testadacompiler.adb
-o CMakeFiles/testadacompiler.dir/testadacompiler.o
gcc: error trying to exec 'gnat1': execvp: No such file
or directory
CMakeFiles/testadacompiler.dir/build.make:60: recipe
for target
`CMakeFiles/testadacompiler.dir/testadacompiler.o'
failed
make[2]: Leaving directory
`/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp'
make[2]: ***
[CMakeFiles/testadacompiler.dir/testadacompiler.o] Error 1
CMakeFiles/Makefile2:66: recipe for target
`CMakeFiles/testadacompiler.dir/all' failed
make[1]: Leaving directory
`/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/Ada/CMakeFiles/CMakeTmp'
make[1]: *** [CMakeFiles/testadacompiler.dir/all] Error
2
Makefile:78: recipe for target `all' failed
make: *** [all] Error 2
CMake will not be able to correctly generate this
project.
Call Stack (most recent call first):
CMakeLists.txt:33 (enable_language)
-- Check for working Ada builder:
GNAT_EXECUTABLE_BUILDER-NOTFOUND -- broken
-- Configuring incomplete, errors occurred!
-- WARNING: no working Ada compiler so disabling Ada
bindings and examples.
-- WARNING: swig not found. Disabling Lua bindings
-- The C compiler identification is GNU 4.5.3
-- Check for working C compiler: /usr/bin/gcc.exe
-- Check for working C compiler: /usr/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
--
'CMAKE_PLATFORM_INFO_DIR=/cygdrive/d/plplot-svn/build-cygwin-dll/language_tests/D/CMakeFiles'
-- CMAKE_GENERATOR = Unix Makefiles
-- D Compiler Install Prefix (use D_PATH env var to
override): CMAKE_D_COMPILER-
CMake Error: your D compiler: "CMAKE_D_COMPILER-NOTFOUND"
was not found. Please set CMAKE_D_COMPILER to a valid
compiler path or name.
-- Configuring incomplete, errors occurred!
-- WARNING: no working D compiler so disabling D bindings
and examples.
-- Check for NaN awareness in C compiler
-- Check for NaN awareness in C compiler - found
-- WARNING: qhull library not found. Setting
PL_HAVE_QHULL to OFF.
-- WARNING: pango not found because pkg-config not
available.
-- Looking for dlopen in dl
-- Looking for dlopen in dl - found
-- Found LTDL: /usr/lib/libltdl.dll.a;/usr/lib/libdl.a
-- LTDL_INCLUDE_DIR = /usr/include
-- LTDL_LIBRARY_DIR = /usr/lib
-- LTDL_LIBRARIES =
/usr/lib/libltdl.dll.a;/usr/lib/libdl.a
-- WARNING: pkg-config not found. Setting cairo drivers to
OFF.
-- WARNING: ENABLE_tk OFF. Setting PLD_tk, PLD_ntk, and
PLD_tkwin OFF.
-- WARNING: pkg-config not found. Setting PLD_psttf to
OFF.
-- Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE
QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE QT_UIC_EXECUTABLE
QT_INCLUDE_DIR QT_LIBRARY_DIR QT_QTCORE_LIBRARY)
-- WARNING: Qt4 development environment not found so
disabling all qt devices.
-- WARNING: PLD_extqt is OFF so setting ENABLE_qt to OFF.
-- WARNING: ENABLE_python is OFF so setting ENABLE_pyqt4
to OFF.
-- Looking for gdi32 header and library
-- Looking for gdi32 header and library - found
-- WARNING: wxWidgets or its libraries not found so
setting all wxwidgets devices to OFF.
-- WARNING: PLD_wxwidgets is OFF so setting
ENABLE_wxwidgets to OFF.
-- WARNING:ocamlc not found. Disabling ocaml bindings
-- WARNING: validate target will not be available to check
for syntax issues in the PLplot DocBook documentation
because onsgmls was not found.
-- WARNING: Perl modules XML::Parser and/or XML::DOM not
available
so cannot check that swig_documentation.i is up to
date.
-- WARNING: pkg-config not found so plplotcanvas_demo,
plplotcanvas_animation, extXdrawable_demo, and
ext-cairo-test not built.
Summary of CMake build system results for PLplot
Install location variables which can be set by the user:
CMAKE_INSTALL_PREFIX: /usr/local
CMAKE_INSTALL_EXEC_PREFIX /usr/local
CMAKE_INSTALL_BINDIR /usr/local/bin
CMAKE_INSTALL_DATADIR /usr/local/share
CMAKE_INSTALL_LIBDIR /usr/local/lib
CMAKE_INSTALL_INCLUDEDIR /usr/local/include
CMAKE_INSTALL_INFODIR /usr/local/share/info
CMAKE_INSTALL_MANDIR /usr/local/share/man
Derived install location variables:
DATA_DIR /usr/local/share/plplot5.9.9
LIB_DIR /usr/local/lib
INCLUDE_DIR /usr/local/include/plplot
BIN_DIR /usr/local/bin
TCL_DIR /usr/local/share/plplot5.9.9/tcl
ADA_INCLUDE_DIR /usr/local/share/ada/adainclude/plplotadad
ADA_LIB_DIR /usr/local/lib/ada/adalib/plplotadad
PYTHON_INSTDIR
DRV_DIR /usr/local/lib/plplot5.9.9/driversd
DOC_DIR /usr/local/share/doc/plplot
MAN_DIR /usr/local/share/man
INFO_DIR /usr/local/share/info
Other important CMake variables:
CMAKE_SYSTEM_NAME: CYGWIN
UNIX: 1
WIN32: 0
APPLE:
MSVC: (MSVC_VERSION: )
MINGW:
MSYS:
CYGWIN: 1
BORLAND:
WATCOM:
SWIG_FOUND: FALSE
PERL_FOUND: TRUE
X11_FOUND: 0
CMAKE_BUILD_TYPE:
CMAKE_C_COMPILER CMAKE_C_FLAGS: /usr/bin/gcc.exe
CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS: /usr/bin/c++.exe
CMAKE_Fortran_COMPILER
CMAKE_Fortran_FLAGS: /usr/bin/gfortran.exe
Target Fortran:
LIB_TAG: d
ENABLE_DYNDRIVERS: ON
DRIVERS_LIST: mem;null;ps;svg;wingcc;xfig
DEVICES_LIST: mem;null;ps;svg;wingcc;xfig
Library options:
BUILD_SHARED_LIBS: ON PL_DOUBLE: ON
Optional libraries:
PL_HAVE_QHULL: OFF WITH_CSA: ON
PL_HAVE_FREETYPE: PL_HAVE_PTHREAD:
HAVE_AGG: HAVE_SHAPELIB: OFF
Language Bindings:
ENABLE_f77: OFF ENABLE_f95: ON
ENABLE_cxx: ON ENABLE_java: OFF
ENABLE_python: OFF ENABLE_octave: OFF
ENABLE_tcl: ON ENABLE_itcl: OFF
ENABLE_tk: OFF ENABLE_itk: OFF
ENABLE_pdl: OFF ENABLE_wxwidgets: OFF
ENABLE_ada: OFF ENABLE_d: OFF
ENABLE_ocaml: OFF ENABLE_lua: OFF
ENABLE_qt: OFF ENABLE_pyqt4: OFF
-- Configuring done
-- Generating done
-- Build files have been written to:
/cygdrive/d/plplot-svn/build-cygwin-dll
----
make output
-----------
Scanning dependencies of target csirocsa
[ 0%] Building C object
lib/csa/CMakeFiles/csirocsa.dir/csa.c.o
Linking C shared library cygcsirocsa-0.dll
[ 0%] Built target csirocsa
Scanning dependencies of target deltaT-gen
[ 0%] Building C object
lib/qsastime/CMakeFiles/deltaT-gen.dir/deltaT-gen.c.o
[ 0%] Building C object
lib/qsastime/CMakeFiles/deltaT-gen.dir/dspline.c.o
Linking C executable deltaT-gen.exe
[ 0%] Built target deltaT-gen
Scanning dependencies of target deltaT.h_built
[ 1%] Generating deltaT.h
[ 1%] Built target deltaT.h_built
Scanning dependencies of target tai-utc-gen
[ 1%] Building C object
lib/qsastime/CMakeFiles/tai-utc-gen.dir/tai-utc-gen.c.o
Linking C executable tai-utc-gen.exe
[ 1%] Built target tai-utc-gen
Scanning dependencies of target tai-utc.h_built
[ 2%] Generating tai-utc.h
[ 2%] Built target tai-utc.h_built
Scanning dependencies of target qsastime
[ 3%] Building C object
lib/qsastime/CMakeFiles/qsastime.dir/qsastime.c.o
[ 3%] Building C object
lib/qsastime/CMakeFiles/qsastime.dir/dsplint.c.o
Linking C shared library cygqsastime-0.dll
[ 3%] Built target qsastime
Scanning dependencies of target plhershey-unicode-gen
[ 3%] Building C object
include/CMakeFiles/plhershey-unicode-gen.dir/__/fonts/plhershey-unicode-gen.c.o
Linking C executable plhershey-unicode-gen.exe
[ 3%] Built target plhershey-unicode-gen
Scanning dependencies of target plhershey-unicode.h_built
[ 4%] Generating plhershey-unicode.h
[ 4%] Built target plhershey-unicode.h_built
Scanning dependencies of target plplotd
[ 4%] Building C object
src/CMakeFiles/plplotd.dir/pdfutils.c.o
[ 5%] Building C object
src/CMakeFiles/plplotd.dir/plaffine.c.o
[ 5%] Building C object
src/CMakeFiles/plplotd.dir/plarc.c.o
[ 5%] Building C object
src/CMakeFiles/plplotd.dir/plargs.c.o
[ 6%] Building C object
src/CMakeFiles/plplotd.dir/plbox.c.o
[ 6%] Building C object
src/CMakeFiles/plplotd.dir/plcont.c.o
[ 6%] Building C object
src/CMakeFiles/plplotd.dir/plcore.c.o
[ 6%] Building C object
src/CMakeFiles/plplotd.dir/plctrl.c.o
[ 8%] Building C object
src/CMakeFiles/plplotd.dir/plcvt.c.o
[ 8%] Building C object
src/CMakeFiles/plplotd.dir/pldtik.c.o
[ 8%] Building C object
src/CMakeFiles/plplotd.dir/plf2ops.c.o
[ 8%] Building C object
src/CMakeFiles/plplotd.dir/plfill.c.o
[ 9%] Building C object
src/CMakeFiles/plplotd.dir/plfreetype.c.o
[ 9%] Building C object
src/CMakeFiles/plplotd.dir/plgradient.c.o
[ 9%] Building C object
src/CMakeFiles/plplotd.dir/plhist.c.o
[ 9%] Building C object
src/CMakeFiles/plplotd.dir/plimage.c.o
[ 10%] Building C object
src/CMakeFiles/plplotd.dir/plline.c.o
[ 10%] Building C object
src/CMakeFiles/plplotd.dir/plmap.c.o
[ 10%] Building C object
src/CMakeFiles/plplotd.dir/plot3d.c.o
[ 10%] Building C object
src/CMakeFiles/plplotd.dir/plpage.c.o
[ 11%] Building C object
src/CMakeFiles/plplotd.dir/plsdef.c.o
[ 11%] Building C object
src/CMakeFiles/plplotd.dir/plshade.c.o
[ 11%] Building C object
src/CMakeFiles/plplotd.dir/plstdio.c.o
[ 11%] Building C object
src/CMakeFiles/plplotd.dir/plstripc.c.o
[ 12%] Building C object
src/CMakeFiles/plplotd.dir/plsym.c.o
[ 12%] Building C object
src/CMakeFiles/plplotd.dir/pltick.c.o
[ 12%] Building C object
src/CMakeFiles/plplotd.dir/plvpor.c.o
[ 13%] Building C object
src/CMakeFiles/plplotd.dir/plwind.c.o
[ 13%] Building C object
src/CMakeFiles/plplotd.dir/plbuf.c.o
[ 13%] Building C object
src/CMakeFiles/plplotd.dir/plgridd.c.o
[ 13%] Building C object
src/CMakeFiles/plplotd.dir/plvect.c.o
[ 15%] Building C object
src/CMakeFiles/plplotd.dir/mt19937ar.c.o
[ 15%] Building C object
src/CMakeFiles/plplotd.dir/pltime.c.o
[ 15%] Building C object
src/CMakeFiles/plplotd.dir/pllegend.c.o
Linking C shared library cygplplotd-11.dll
[ 15%] Built target plplotd
Scanning dependencies of target plplotcxxd
[ 15%] Building CXX object
bindings/c++/CMakeFiles/plplotcxxd.dir/plstream.cc.o
Linking CXX shared library cygplplotcxxd-10.dll
[ 15%] Built target plplotcxxd
Scanning dependencies of target plplotf95cd
[ 15%] Building C object
bindings/f95/CMakeFiles/plplotf95cd.dir/sc3d.c.o
[ 16%] Building C object
bindings/f95/CMakeFiles/plplotf95cd.dir/sccont.c.o
[ 16%] Building C object
bindings/f95/CMakeFiles/plplotf95cd.dir/scstubs.c.o
Linking C shared library cygplplotf95cd-9.dll
[ 16%] Built target plplotf95cd
Scanning dependencies of target plplotf95d
[ 16%] Building Fortran object
bindings/f95/CMakeFiles/plplotf95d.dir/strutil.f90.o
[ 17%] Building Fortran object
bindings/f95/CMakeFiles/plplotf95d.dir/sfstubsf95.f90.o
[ 17%] Building Fortran object
bindings/f95/CMakeFiles/plplotf95d.dir/configurable.f90.o
Linking Fortran shared library cygplplotf95d-9.dll
[ 17%] Built target plplotf95d
Scanning dependencies of target plplot.tcl_target
[ 17%] Generating plplot.tcl
[ 17%] Built target plplot.tcl_target
Scanning dependencies of target tclmatrixd
[ 18%] Building C object
bindings/tcl/CMakeFiles/tclmatrixd.dir/tclMatrix.c.o
[ 18%] Building C object
bindings/tcl/CMakeFiles/tclmatrixd.dir/matrixInit.c.o
Linking C shared library cygtclmatrixd-9.dll
[ 18%] Built target tclmatrixd
[ 18%] Generating tclgen.h, tclgen_s.h, tclgen.c
Scanning dependencies of target plplottcltkd
[ 18%] Building C object
bindings/tcl/CMakeFiles/plplottcltkd.dir/tclAPI.c.o
[ 18%] Building C object
bindings/tcl/CMakeFiles/plplottcltkd.dir/tclMain.c.o
Linking C shared library cygplplottcltkd-9.dll
[ 18%] Built target plplottcltkd
Scanning dependencies of target tclIndex_tcl
[ 18%] Generating tclIndex
[ 18%] Built target tclIndex_tcl
Scanning dependencies of target mem
[ 18%] Building C object
drivers/CMakeFiles/mem.dir/mem.c.o
Linking C shared module mem.dll
[ 18%] Built target mem
Scanning dependencies of target null
[ 19%] Building C object
drivers/CMakeFiles/null.dir/null.c.o
Linking C shared module null.dll
[ 19%] Built target null
Scanning dependencies of target ps
[ 19%] Building C object drivers/CMakeFiles/ps.dir/ps.c.o
Linking C shared module ps.dll
[ 19%] Built target ps
Scanning dependencies of target svg
[ 19%] Building C object
drivers/CMakeFiles/svg.dir/svg.c.o
Linking C shared module svg.dll
[ 19%] Built target svg
Scanning dependencies of target test-drv-info
[ 19%] Building C object
drivers/CMakeFiles/test-drv-info.dir/test-drv-info.c.o
Linking C executable test-drv-info.exe
[ 19%] Built target test-drv-info
Scanning dependencies of target xfig
[ 20%] Building C object
drivers/CMakeFiles/xfig.dir/xfig.c.o
Linking C shared module xfig.dll
[ 20%] Built target xfig
Scanning dependencies of target test_xfig_dyndriver
[ 20%] Generating test_dyndrivers_dir/xfig.driver_info
Could not open driver module xfig
libltdl error: The specified module could not be found.
drivers/CMakeFiles/test_xfig_dyndriver.dir/build.make:55:
recipe for target
`drivers/test_dyndrivers_dir/xfig.driver_info' failed
make[2]: ***
[drivers/test_dyndrivers_dir/xfig.driver_info] Error 1
CMakeFiles/Makefile2:2470: recipe for target
`drivers/CMakeFiles/test_xfig_dyndriver.dir/all' failed
make[1]: ***
[drivers/CMakeFiles/test_xfig_dyndriver.dir/all] Error 2
Makefile:146: recipe for target `all' failed
make: *** [all] Error 2
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
|
|
From: Alan W. I. <ir...@be...> - 2013-07-12 09:20:20
|
On 2013-07-12 09:53+0200 Arjen Markus wrote: Hi Arjen: Those ldd results showed only system libraries were found. I guess it is possible there is some problem with ldd for non-system libraries, but it is probably more likely the ??? is saying there are linking problems. However, as yet you do not have the definitive evidence concerning that. One issue is time and again on Windows platforms our test case fails for the dynamic devices while the library use succeeds. Nobody has ever been able to explain this, but since the test case seems unreliable, I suggest you just drop it until we can figure out what is wrong with the test by using the CMake option -DTEST_DYNDRIVERS=OFF. Another issue is you forgot to specify VERBOSE=1. Could you try again using, e.g., make VERBOSE=1 test_noninteractive >& test_noninteractive.out ? Also, please put the *.out files + requested CMake Cache file in a compressed tarball so they are not subject to e-mail line wrap. Those requested VERBOSE=1 results should give the exact commands used for linking and thus give the definitive story about whether rpath was used or not. In any case with -DTEST_DYNDRIVERS=OFF and assuming cmake does specify the correct linking commands that include -rpath, you should get a lot further into the test. 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 __________________________ |
|
From: Arjen M. <arj...@de...> - 2013-07-12 09:29:08
|
Hi Alan, when I received my email I noticed this very odd line wrapping. No idea how I can prevent that, as they were very different from what I saw when I typed the message. Anyway, I will redo the build using VERBOSE and TEST_DYNDRIVERS off and report via a tgz-file. (Dynamic drivers work fine under Windows, bare and MinGW, but there is definitely something odd going on.) Regards, Arjen On Fri, 12 Jul 2013 02:20:12 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > On 2013-07-12 09:53+0200 Arjen Markus wrote: > > Hi Arjen: > > Those ldd results showed only system libraries were >found. > I guess it is possible there is some problem with ldd >for non-system > libraries, but it is probably more likely the ??? is >saying there > are linking problems. However, as yet you do not have >the > definitive evidence concerning that. > > One issue is time and again on Windows platforms our >test case fails for > the dynamic devices while the library use succeeds. > Nobody > has ever been able to explain this, but since the test > case seems unreliable, I suggest you just drop it until >we > can figure out what is wrong with the test by using > the CMake option -DTEST_DYNDRIVERS=OFF. > > Another issue is you forgot to specify VERBOSE=1. Could >you try again > using, e.g., > > make VERBOSE=1 test_noninteractive >& >test_noninteractive.out > > ? > > Also, please put the *.out files + requested CMake Cache >file in a compressed > tarball so they are not subject to e-mail line wrap. > > Those requested VERBOSE=1 results should give the exact >commands used > for linking and thus give the definitive story about >whether rpath was > used or not. In any case with -DTEST_DYNDRIVERS=OFF and >assuming > cmake does specify the correct linking commands that >include -rpath, > you should get a lot further into the test. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-12 09:58:18
|
On 2013-07-12 11:28+0200 Arjen Markus wrote: > Hi Alan, > > when I received my email I noticed this very odd line wrapping. > No idea how I can prevent that, as they were very different > from what I saw when I typed the message. > > Anyway, I will redo the build using VERBOSE and TEST_DYNDRIVERS off > and report via a tgz-file. (Dynamic drivers work fine under Windows, > bare and MinGW, but there is definitely something odd going on.) Just one more thing before I go to sleep. I just did a quick search for -rpath and Cygwin, and it appears it does work in simple cases. So there is still good hope the current approach will work. But if it turns out not, then I can quickly change the build system logic to implement the dll workaround for cygwin. 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 __________________________ |
|
From: Arjen M. <arj...@de...> - 2013-07-12 11:10:21
Attachments:
verbose.tgz
|
Hi Alan, On Fri, 12 Jul 2013 02:58:10 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > > Just one more thing before I go to sleep. I just did a >quick search > for -rpath and Cygwin, and it appears it does work in >simple cases. So there is still good hope the current >approach will work. But if > it turns out not, then I can quickly change the build >system > logic to implement the dll workaround for cygwin. > The result of: "cmake -DBUILD_TEST=ON -DENABLE_DYNDRIVERS=OFF" and "make VERBOSE=1" is in the attached tgz file. It fails again on loading a DLL - this time in x00c, the very first test run. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-12 19:46:16
|
IMPORTANT message for everybody lurking on this list. Revision 12419 (referred to below) updates the minimum acceptable CMake version to 2.8.9. This effectively updates all CMake policies (interpretations of CMake logic) so revision 12419 needs lots more testing. See the commit message for revision 12419 for additional comments about this. The rest of this is mainly directed at Arjen On 2013-07-12 13:10+0200 Arjen Markus wrote: > Hi Alan, > > On Fri, 12 Jul 2013 02:58:10 -0700 (PDT) > "Alan W. Irwin" <ir...@be...> wrote: > >> >> Just one more thing before I go to sleep. I just did a quick search >> for -rpath and Cygwin, and it appears it does work in simple cases. So >> there is still good hope the current approach will work. But if >> it turns out not, then I can quickly change the build system >> logic to implement the dll workaround for cygwin. >> > > The result of: > > "cmake -DBUILD_TEST=ON -DENABLE_DYNDRIVERS=OFF" > and "make VERBOSE=1" > > is in the attached tgz file. Hi Arjen: I am afraid the combination of the issues below that I have noted means another test is requested. What a big surprise. :-) Here are the details: Your cmake.out file reveals some important issues. 1. -- The C compiler identification is GNU 4.5.3 That must mean you are using a rather old version of Cygwin that needs to be updated (or better yet installed from scratch to preserve your old version for comparison). The version of gcc should be at least 4.7.x from my experience with MinGW/MSYS. 2. The warning concerning CMAKE_LEGACY_CYGWIN_WIN32 not being set to 0. It was being set (to OFF, but that should not matter) before, but I think it was probably done in the wrong order. As of revision 12419 I have adopted the same order as used for the build of CMake itself and that should hopefully quiet this message. By the way, I am pretty sure there are no practical consequences to this warning message because the resulting WIN32 variable is false and the resulting CYGWIN variable is true. But for your retest, please check that the new reordering has quieted the message. 3. WARNING: ENABLE_DYNDRIVERS is OFF. It is important that your retest be done with ENABLE_DYNDRIVERS ON since that is the most heavily tested version of PLplot on all platforms. Once ENABLE_DYNDRIVERS ON works on Cygwin, then by all means try other possiblities such as ENABLE_DYNDRIVERS OFF. Your make.out file reveals one extremely important issue. CMake generated no -rpath options for linking! There is some anecdotal evidence on the web that -rpath actually works on Cygwin, but clearly the CMake engineers (at least for version 2.8.9 which you are currently using) do not trust -rpath on Cygwin or are unaware of that capability because CMake doesn't even try to use the rpath option on that platform. So only the dll workaround will work, and I have no clue how your previous Cygwin tests worked at all unless you manually did something like that dll workaround. As of revision 12420 I have changed our build system logic so that the dll subdirectory workaround is used only for shared libraries and for WIN32_OR_CYGWIN. I have now deployed an additional variable (USE_DLL_SUBDIRECTORY) to control when this workaround is used so any further changes in our policy concerning this will only require a change in one place (where USE_DLL_SUBDIRECTORY is defined). Please give revision 12420 a try with ENABLE_DYNDRIVERS ON. Win or lose, I would again like to see complete results, i.e, all the *.out files (using VERBOSE=1), and the CMakeCache.txt file. It didn't matter this time, but you forgot to include that latter file in the current tarball. Can you automate collection of files in that tarball with a script and also automate the use of VERBOSE=1 so I always get from you the full results requested? Also, if you make it a practice to automatically collect full results of the Cygwin build in a tarball, they should be useful to you in future when you are wondering what the last build and test results were for the Cygwin platform. Thanks in advance for the next test. 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 __________________________ |
|
From: Arjen M. <arj...@de...> - 2013-07-15 06:35:27
|
Hi Alan, On 2013-07-12 21:46, Alan W. Irwin wrote: > > Hi Arjen: > > I am afraid the combination of the issues below that I have noted means > another test is requested. What a big surprise. :-) > > Here are the details: > > Your cmake.out file reveals some important issues. > > 1. -- The C compiler identification is GNU 4.5.3 > > That must mean you are using a rather old version of Cygwin that > needs to be updated (or better yet installed from scratch to > preserve your old version for comparison). The version > of gcc should be at least 4.7.x from my experience with MinGW/MSYS. > Actually, I installed it a-fresh last month. Therefore I did not pay any attention to the GCC version. But prompted by your discovery I checked with the Cygwin setup program again and now my Cygwin installation has version 4.7.3 - could this have anything to do with the FTP mirror I used? > 2. The warning concerning CMAKE_LEGACY_CYGWIN_WIN32 not being set to > 0. It was being set (to OFF, but that should not matter) before, but > I think it was probably done in the wrong order. As of revision 12419 > I have adopted the same order as used for the build of CMake itself > and that should hopefully quiet this message. By the way, I am pretty > sure there are no practical consequences to this warning message because > the resulting WIN32 variable is false and the resulting CYGWIN variable > is true. But for your retest, please check that the new reordering > has quieted the message. Will do. These warnings look a trifle menacing for unsuspecting users, so we definitely don't want them :). > > 3. WARNING: ENABLE_DYNDRIVERS is OFF. > > It is important that your retest be done with ENABLE_DYNDRIVERS ON > since that is the most heavily tested version of PLplot on all > platforms. Once ENABLE_DYNDRIVERS ON works on Cygwin, then by all > means try other possiblities such as ENABLE_DYNDRIVERS OFF. > Clear. > Your make.out file reveals one extremely important issue. > > CMake generated no -rpath options for linking! There is some anecdotal > evidence on the web that -rpath actually works on Cygwin, but clearly > the CMake engineers (at least for version 2.8.9 which you are > currently using) do not trust -rpath on Cygwin or are unaware of that > capability because CMake doesn't even try to use the rpath option on > that platform. So only the dll workaround will work, and I have no > clue how your previous Cygwin tests worked at all unless you manually > did something like that dll workaround. > > As of revision 12420 I have changed our build system logic so that the > dll subdirectory workaround is used only for shared libraries and for > WIN32_OR_CYGWIN. I have now deployed an additional variable > (USE_DLL_SUBDIRECTORY) to control when this workaround is used so > any further changes in our policy concerning this will only > require a change in one place (where USE_DLL_SUBDIRECTORY is defined). > > Please give revision 12420 a try with ENABLE_DYNDRIVERS ON. Win or > lose, I would again like to see complete results, i.e, all the *.out > files (using VERBOSE=1), and the CMakeCache.txt file. It didn't > matter this time, but you forgot to include that latter file in the > current tarball. Can you automate collection of files in that tarball > with a script and also automate the use of VERBOSE=1 so I always get > from you the full results requested? Also, if you make it a practice > to automatically collect full results of the Cygwin build in a > tarball, they should be useful to you in future when you are wondering > what the last build and test results were for the Cygwin platform. > > Thanks in advance for the next test. Such automation should be a jiffy. I will take care of that for this coming test (I normally run CMake via a batch file/shell script anyway, to avoid having to remember the correct path and options ;)). Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Arjen M. <arj...@de...> - 2013-07-16 10:50:11
Attachments:
plplot_test.tar.gz
|
Hi Alan, I have attached the results of the test as a gzipped tar file. Note 1: The non-interative test fails because the file tclIndex is not present in the examples/tcl directory. Note 2: the current configuration does not build the wingcc device, which is the most common interactive device on Windows. I found that out when I tried to see if the Tcl examples would work. (They do, the xfig file I generated for example 1 is identical to the C one) Regards, Arjen On 2013-07-12 21:46, Alan W. Irwin wrote: > IMPORTANT message for everybody lurking on this list. > Revision 12419 (referred to below) updates the minimum acceptable CMake > version > to 2.8.9. This effectively updates all CMake policies (interpretations > of CMake logic) so revision 12419 needs lots more testing. See the > commit message for revision 12419 for additional comments about this. > > The rest of this is mainly directed at Arjen > > On 2013-07-12 13:10+0200 Arjen Markus wrote: > >> Hi Alan, >> >> On Fri, 12 Jul 2013 02:58:10 -0700 (PDT) >> "Alan W. Irwin" <ir...@be...> wrote: >> >>> >>> Just one more thing before I go to sleep. I just did a quick search >>> for -rpath and Cygwin, and it appears it does work in simple cases. >>> So there is still good hope the current approach will work. But if >>> it turns out not, then I can quickly change the build system >>> logic to implement the dll workaround for cygwin. >>> >> >> The result of: >> >> "cmake -DBUILD_TEST=ON -DENABLE_DYNDRIVERS=OFF" >> and "make VERBOSE=1" >> >> is in the attached tgz file. > > Hi Arjen: > > I am afraid the combination of the issues below that I have noted means > another test is requested. What a big surprise. :-) > > Here are the details: > > Your cmake.out file reveals some important issues. > > 1. -- The C compiler identification is GNU 4.5.3 > > That must mean you are using a rather old version of Cygwin that > needs to be updated (or better yet installed from scratch to > preserve your old version for comparison). The version > of gcc should be at least 4.7.x from my experience with MinGW/MSYS. > > 2. The warning concerning CMAKE_LEGACY_CYGWIN_WIN32 not being set to > 0. It was being set (to OFF, but that should not matter) before, but > I think it was probably done in the wrong order. As of revision 12419 > I have adopted the same order as used for the build of CMake itself > and that should hopefully quiet this message. By the way, I am pretty > sure there are no practical consequences to this warning message because > the resulting WIN32 variable is false and the resulting CYGWIN variable > is true. But for your retest, please check that the new reordering > has quieted the message. > > 3. WARNING: ENABLE_DYNDRIVERS is OFF. > > It is important that your retest be done with ENABLE_DYNDRIVERS ON > since that is the most heavily tested version of PLplot on all > platforms. Once ENABLE_DYNDRIVERS ON works on Cygwin, then by all > means try other possiblities such as ENABLE_DYNDRIVERS OFF. > > Your make.out file reveals one extremely important issue. > > CMake generated no -rpath options for linking! There is some anecdotal > evidence on the web that -rpath actually works on Cygwin, but clearly > the CMake engineers (at least for version 2.8.9 which you are > currently using) do not trust -rpath on Cygwin or are unaware of that > capability because CMake doesn't even try to use the rpath option on > that platform. So only the dll workaround will work, and I have no > clue how your previous Cygwin tests worked at all unless you manually > did something like that dll workaround. > > As of revision 12420 I have changed our build system logic so that the > dll subdirectory workaround is used only for shared libraries and for > WIN32_OR_CYGWIN. I have now deployed an additional variable > (USE_DLL_SUBDIRECTORY) to control when this workaround is used so > any further changes in our policy concerning this will only > require a change in one place (where USE_DLL_SUBDIRECTORY is defined). > > Please give revision 12420 a try with ENABLE_DYNDRIVERS ON. Win or > lose, I would again like to see complete results, i.e, all the *.out > files (using VERBOSE=1), and the CMakeCache.txt file. It didn't > matter this time, but you forgot to include that latter file in the > current tarball. Can you automate collection of files in that tarball > with a script and also automate the use of VERBOSE=1 so I always get > from you the full results requested? Also, if you make it a practice > to automatically collect full results of the Cygwin build in a > tarball, they should be useful to you in future when you are wondering > what the last build and test results were for the Cygwin platform. > > Thanks in advance for the next test. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-16 20:49:53
|
On 2013-07-16 12:49+0200 Arjen Markus wrote:
> Hi Alan,
>
> I have attached the results of the test as a gzipped tar file.
Thanks for those results. Here are some issues I spotted.
1. Clearly my attempt to quiet the "WIN32 not defined on Cygwin"
warning messages didn't work in the slightest so I am now following
directions exactly (revision 12425) by not setting
CMAKE_LEGACY_CYGWIN_WIN32 as an ordinary non-cached variable. Instead,
the directions say to quiet the warning messages for CMake 2.8.4 and
above (the current case) you must set that variable as a cached
variable. To do that, please use -DCMAKE_LEGACY_CYGWIN_WIN32=0 as a cmake
command option in your automated testing script for Cygwin just to see
if that finally gets rid of those annoying warnings.
2. Although it didn't affect anything this time for unknown reasons,
please use -DTEST_DYNDRIVERS=OFF in your automatic testing script
for the reasons discussed before.
> Note 1: The non-interative test fails because the file tclIndex is not
> present in the examples/tcl directory.
Debugging issues like this is why the VERBOSE=1 option is so useful.
Please look at make.out where an attempt is made to create that file:
[ 52%] Generating tclIndex
cd /cygdrive/d/plplot-svn/build-cygwin-dll/examples/tcl && /bin/tclsh /cygdrive/d/plplot-svn/plplot/scripts/mktclIndex -tcl
make[3]: Leaving directory `/cygdrive/d/plplot-svn/build-cygwin-dll'
/usr/bin/cmake.exe -E cmake_progress_report /cygdrive/d/plplot-svn/build-cygwin-dll/CMakeFiles 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
[ 74%] Built target tclIndex_examples_tcl
The equivalent works fine on Linux. Please try to replicate those
exact commands by hand to see what the issue might be on Cygwin.
Note, the above commands were generated by the CMake logic in
examples/tcl/CMakeLists.txt which currently reads
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/tclIndex
COMMAND ${TCL_TCLSH} ${MKTCLINDEX} ${MKTCLINDEX_ARGS}
DEPENDS ${tclIndex_DEPENDS}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
So if some change needs to be made to the CMake logic, it will be in
the above area or else the CMake logic where the CMake MKTCLINDEX or
MKTCLINDEX_ARGS variables are defined. Or if a change needs
to be made to mktclIndex for Cygwin, I am sure you will know what
is required. So if you can somehow solve this issue,
I look forward to your commit.
Of course, if you cannot generate tclIndex by hand by some variation
of the above mktclIndex command (i.e., there is probably a Cygwin bug
that you cannot do anything about other than to report to Cygwin),
then to proceed further with that platform you must specify
-DENABLE_tcl=OFF until that Cygwin bug is fixed.
>
> Note 2: the current configuration does not build the wingcc device,
> which is the most common interactive device on Windows. I found that
> out when I tried to see if the Tcl examples would work. (They do,
> the xfig file I generated for example 1 is identical to the C one)
The test_noninteractive target only builds the minimum (which does not
include the interactive wingcc device) needed to do the non-
interactive tests. That is by design so the test will be run as
rapidly as possible with only the required dependencies built.
If instead you want to test all interactive devices (including
wingcc), then run the test_interactive target (before or after
test_noninteractive since the dependencies insure the order for
invoking these targets does not matter).
I look forward to the command-line ouput for both those targets
(please captured as test_noninteractive.out and test_interactive out
in your next tarball).
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
__________________________
|
|
From: Arjen M. <arj...@de...> - 2013-07-17 11:11:22
|
Hi Alan, On Tue, 16 Jul 2013 13:49:45 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: >> Note 1: The non-interative test fails because the file >>tclIndex is not >> present in the examples/tcl directory. > > Debugging issues like this is why the VERBOSE=1 option >is so useful. > Please look at make.out where an attempt is made to >create that file: > > [ 52%] Generating tclIndex > cd /cygdrive/d/plplot-svn/build-cygwin-dll/examples/tcl >&& /bin/tclsh >/cygdrive/d/plplot-svn/plplot/scripts/mktclIndex -tcl > make[3]: Leaving directory >`/cygdrive/d/plplot-svn/build-cygwin-dll' > /usr/bin/cmake.exe -E cmake_progress_report >/cygdrive/d/plplot-svn/build-cygwin-dll/CMakeFiles 29 30 >31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 > [ 74%] Built target tclIndex_examples_tcl > > The equivalent works fine on Linux. Please try to >replicate those > exact commands by hand to see what the issue might be on >Cygwin. > Note, the above commands were generated by the CMake >logic in > examples/tcl/CMakeLists.txt which currently reads > The cause was trivial: somehow, again!, the file permissions for one of the files in question (x16.tcl) got messed up and the mktclIndex script could not read it. No message was sent to the screen about that, as the errors were caught via Tcl's [catch] command. To prevent this from happening again, I have made sure the error message will be printed. As for the wingcc device: I thought I had run into a Cygwin versus Windows problem, as the device belongs to the Windows platform, but you are most likely right: just the minimum of devices. Well, running a further test now ... Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Arjen M. <arj...@de...> - 2013-07-17 11:21:41
|
On Wed, 17 Jul 2013 13:11:03 +0200 "Arjen Markus" <arj...@de...> wrote: > > Well, running a further test now ... > The test has completed, but the final report claims there are (almost) no Tcl test results available. This turns out to be due to a strange character in the name of the PS-files that are generated: UNICODE "0DF0" The name is now something like: x01t.psc? (where ? is the above character) This will require further investigation ... Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-17 16:50:22
|
On 2013-07-17 13:21+0200 Arjen Markus wrote: > On Wed, 17 Jul 2013 13:11:03 +0200 > "Arjen Markus" <arj...@de...> wrote: > >> >> Well, running a further test now ... >> > > The test has completed, but the final report claims there > are (almost) no Tcl test results available. This turns out > to be due to a strange character in the name of the PS-files > that are generated: UNICODE "0DF0" > The name is now something like: x01t.psc? > (where ? is the above character) > > This will require further investigation ... According to my resources 0DF0 is an unassigned unicode character so that is a pretty peculiar symptom. My strong advice for dealing with such issues is to simplify, simplify, and then do it again. There are two possible outcomes to that simplification process. (1) You will be able to remove PLplot from the equation and end up with a simple tcl script with no reference to PLplot that can be executed using tclsh that clearly shows the bad filename for the file that is created. In this case, you can use that simple example in a bug report to the Cygwin mailing list. (2) You will prove that the issue only occurs when PLplot is part of the mix. In which case it is a PLplot bug that is exposed for Tcl/Cygwin which we will have to figure out. I also wanted to emphasize your most important result which is that you got the test_noninteractive target to work properly for the first time on the Cygwin platform. Congratulations on that achievement! I suggest you follow up on that achievement by installing a much more comprehensive Cygwin. Your goal should be to eliminate most/all the warning messages in cmake.out about missing components. In particular, I know from searching at http://cygwin.com/packages that official Cygwin packages exist for at least pkg-config, swig, python, java, lua, pango, and Qt4, and once those are installed your cmake.out warning messages will likely guide you to several more Cygwin packages that you should install. Installing additional components of Cygwin is important since it allows you to finally do a comprehensive test of most/all of the PLplot functionality on Cygwin. You will likely have to disable some of the potential components, (e.g., Tk for the reasons we have mentioned before). But knowing what the boundaries are and having good test results for everything inside the boundaries should be a lot of help to Cygwin users of PLplot. In addition, this follow up should be personally useful to you since I think you will be amazed at the quality of the PLplot results that can be achieved with, e.g., the qt devices or the cairo devices. 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 __________________________ |
|
From: Arjen M. <arj...@de...> - 2013-07-19 08:10:39
|
Hi Alan, > > Installing additional components of Cygwin is important >since it > allows you to finally do a comprehensive test of >most/all of the > PLplot functionality on Cygwin. You will likely have to >disable some > of the potential components, (e.g., Tk for the reasons >we have > mentioned before). But knowing what the boundaries are >and having > good test results for everything inside the boundaries >should be a lot > of help to Cygwin users of PLplot. In addition, this >follow up should > be personally useful to you since I think you will be >amazed at the > quality of the PLplot results that can be achieved with, >e.g., the qt > devices or the cairo devices. > I have installed a few more components, SWIG and Cairo among others, and now I am testing the whole lot. Surprisingly, I have an X Window driver now and a Tk driver. More exploration is required to see what they can do, but the build process was smooth. Well, apart from this obscure file permissions issue, but I can handle that. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Arjen M. <arj...@de...> - 2013-07-18 08:22:53
|
Hi Alan,
On Wed, 17 Jul 2013 09:50:08 -0700 (PDT)
"Alan W. Irwin" <ir...@be...> wrote:
>
> According to my resources 0DF0 is an unassigned unicode
>character so
> that is a pretty peculiar symptom. My strong advice for
>dealing with
> such issues is to simplify, simplify, and then do it
>again. There are
> two possible outcomes to that simplification process.
>(1) You will be
> able to remove PLplot from the equation and end up with
>a simple tcl
> script with no reference to PLplot that can be executed
>using tclsh
> that clearly shows the bad filename for the file that is
>created. In
> this case, you can use that simple example in a bug
>report to the
> Cygwin mailing list. (2) You will prove that the issue
>only occurs
> when PLplot is part of the mix. In which case it is a
>PLplot bug that
> is exposed for Tcl/Cygwin which we will have to figure
>out.
>
I simplified the procedure by simply calling pltcl
directly
with the arguments I found in the test script. This
resulted
in a file with the correct extension.
Then I added one complication: I called bash with the x01
script - a mixture of shell scripting and Tcl programming.
Bingo!
The shell magic 'exec pltcl -f "$0" ${1+"$@"}' is the
culprit.
There is a simple workaround: add an extra (empty)
argument
after the last. This will get the mysterious character
appended and the file name is left untouched.
I will report this on the Cygwin list later.
As for the rest of your message: thanks for the
compliments
and yes, getting all the other stuff in ought to be easy
enough. Then testing the full(er) range of capabilities
will be a jiffy indeed, even if it requires more patience
:).
It should be no problem to do that before my holidays
(in a week's time). Then there is example 33 for Tcl of
course - and a bit of example 16. Hopefully I can finish
that too.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
|
|
From: Arjen M. <arj...@de...> - 2013-07-18 10:02:22
|
Hi Alan,
On Thu, 18 Jul 2013 10:22:32 +0200
"Arjen Markus" <arj...@de...> wrote:
> Then I added one complication: I called bash with the
>x01
> script - a mixture of shell scripting and Tcl
>programming.
> Bingo!
>
> The shell magic 'exec pltcl -f "$0" ${1+"$@"}' is the
> culprit.
>
> There is a simple workaround: add an extra (empty)
> argument
> after the last. This will get the mysterious character
> appended and the file name is left untouched.
>
> I will report this on the Cygwin list later.
>
When I tried to reproduce this in a small script, I found
that the extraneous character is a carriage return. This
may be a consequence of the newline ambiguity in Windows:
CRLF versus LF.
Investigating further
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
|
|
From: Arjen M. <arj...@de...> - 2013-07-19 08:06:56
|
Hello, I am trying to run the Python examples under Cygwin, but I get the message from example 1 that it can not find the _plplotc module. Is there some environment variable required, like LD_LIBRARY_PATH or PATH? (The PATH variable points to the directory that contains the _plplotc.pyd file, but that, apparently, is not enough.) Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
|
From: Alan W. I. <ir...@be...> - 2013-07-19 11:20:15
|
On 2013-07-19 10:06+0200 Arjen Markus wrote: > Hello, > > I am trying to run the Python examples under Cygwin, but > I get the message from example 1 that it can not find the > _plplotc module. Is there some environment variable required, > like LD_LIBRARY_PATH or PATH? (The PATH variable points to > the directory that contains the _plplotc.pyd file, but that, > apparently, is not enough.) Hi Arjen: Is the problem, perhaps, the module name in the dll subdirectory does not have the correct form to be recognized by Cygwin Python? The current CMake logic concerning that name (from bindings/python/CMakeLists.txt) is if(WIN32_OR_CYGWIN) set_target_properties( _plplotcmodule PROPERTIES SUFFIX ".pyd" OUTPUT_NAME "_plplotc" ) endif(WIN32_OR_CYGWIN) So the resulting name (for MSVC, MinGW, MinGW/MSYS, and Cygwin currently) is _plplotc.pyd in the dll subdirectory. Since that is not working for you, my guess is the name should be _plplotc.dll in that same subdirectory just for the Cygwin case. If your tests show that guess (or one of your own) is correct, then please change the above logic to if(WIN32_AND_NOT_CYGWIN) [...] current stanza elseif(CYGWIN) [...] modified stanza endif(WIN32_AND_NOT_CYGWIN) to automatically create the correct name form for the Cygwin case without disrupting the other platforms I have mentioned. 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 __________________________ |
|
From: Arjen M. <arj...@de...> - 2013-07-19 11:27:45
|
Hi Alan, On Fri, 19 Jul 2013 04:20:06 -0700 (PDT) "Alan W. Irwin" <ir...@be...> wrote: > > Is the problem, perhaps, the module name in the dll >subdirectory does > not have the correct form to be recognized by Cygwin >Python? > Yes, I copied the file _plplotc.pyd to _plplotc.dll and now it is working - even without the PYTHONPATH variable I found in the documentation. Running the tests now ... I will change the logic, as per your suggestion. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
