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. |