From: Alan W. I. <ir...@be...> - 2013-12-13 21:49:20
|
The short story is I have decided to put off the release to early next week (if a lot of progress is made over the weekend) or even later in the week. Now here is the longer story about where we stand with this release. @Arjen: I very much appreciate the guidance you have given about the problems Phil has been finding. Here are the Windows issues as I understand them now from what Arjen has said, but please correct this summary if I get something wrong. (1) The "Visual Studio 11" generator (for the VS2012 IDE) is not working correctly. This is likely (see below for my own conclusions confirming that) an inherent CMake bug and nothing to do with PLplot. So according to Arjen's advice we note the issue but do not delay the release because of it. After all, it is not a showstopper for individuals with VS2012 since nmake should always be available to them for building PLplot. (2) Subsequently, Arjen found similar but less severe issues with the "Visual Studio 10" generator (for the VS2010 IDE), but I assume we should treat this the same as (1). (3) Phil has found the following issue which I spotted in the CMake output that he sent for the "Visual Studio 11" generator: CMake Error at cmake/modules/plplot_functions.cmake:210 (list): list sub-command REMOVE_DUPLICATES requires list to be present. Call Stack (most recent call first): cmake/modules/shapelib.cmake:34 (filter_rpath) cmake/modules/plplot.cmake:513 (include) CMakeLists.txt:111 (include) That error message implies none of CMAKE_C_IMPLICIT_LINK_DIRECTORIES, CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES, or CMAKE_FORTRAN_IMPLICIT_LINK_DIRECTORIES are defined which is impossible (!) according to the CMake documentation. My conclusion from this is the "Visual Studio 11" generator is severely broken. Neverthless, I did make the filter_rpath command robust against this unexpected bad result for those variables in revision 12864. (4) Phil has found a really strange -L+ issue where the workaround is to set -DENABLE_d=OFF. I assume that issue is also for the "Visual Studio 11" generator. @Phil: I strongly second Arjen's suggestion that you move to nmake for now. Once we have that working perfectly for you, then we can go back (post-release) to try and figure out what is wrong with VS2012 (which will likely involve CMake bug reports rather than anything to do with PLplot). If you agree this is the right approach, would you please try the "NMake Makefiles" generator as soon as possible, and let us know if (a) there are any cmake issues left for that case, and (b) assuming all is well with the cmake results, does the PLplot build with nmake work and pass all your usual tests? Of course, there are still some uncertainties about the Windows platform until Phil responds to the above request, but my guess from Arjen's good experiences with nmake is that it will work well for Phil as well. IMPORTANT. But if Phil does find nmake issues for his platform, I would view those as release critical so I would be willing to delay the release until you guys figure out whatever that (hypothetical) problem is. As far as I know there are no release-critical Mac OS X issues. Jerry did find a general issue with the test logic that I recently fixed, but my understanding from what he has said is everything else has been working well for him on that platform. Here is the summary of the remaining release-critical issues for the Linux platform (including the reason I have decided to delay the release for at least a few days). I discovered these issues as a result of the option for comprehensive testing of PLplot I enabled last night for the epa_build project. (1) A potential showstopper was segfaults for -dev tk for the combination of Tcl/Tk8.6 and using the stubs version of the Tcl/Tk libraries. I have worked around this issue for this release by switching back to using the ordinary Tcl/Tk libraries by default (the approach we had been using until last month). But using the stubs versions of the Tcl/Tk libraries is highly recommended by the Tcl/Tk developers. They also strongly suggest (as do I) moving from the deprecated Tcl/Tk API we currently use to the recommended Tcl/Tk API. That may solve the segfault issue, but there are obviously a lot of high-priority changes we need to make in the Tcl/Tk bindings and examples post-release. (2) There is a build-system inconsistency about the pkg-config version that is being used. I hope to address that today. (3) The real issue with a release this weekend (assuming nmake is fine for Phil) is I am suddenly at least a couple of days behind the schedule I worked out for this release. For example, I still have plans to do one more complete round of testing via epa_build on Linux and also on MinGW/MSYS/Wine, and there are bound to be some issues to fix especially for the latter platform. So the start of the release process which I had planned for Thursday morning is likely only going to happen Monday morning at the earliest. In sum, there is still some open-ended stuff to do for this release on Linux, MinGW/MSYS/Wine and also possibly MSVC/nmake platforms so it is hard to predict exact timing, but my guess is it going to be at least Monday morning before I start the actual release process and at least Tuesday before I finish that release process. But I will keep you guys informed as the currently large uncertainties gradually disappear about when the release will actually happen. I also am taking this opportunity to publicly thank everybody who has been so heavily testing PLplot these last few days. The fixes that have resulted from that testing have already added greatly to the quality of this forthcoming release! 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: phil r. <phi...@ya...> - 2013-12-14 11:08:56
|
Hi All So here is my current status building Plplot with VC++ 2012 and wxWidgets 3.0, for both 32 and 64 bit. CMake now completes the for the latest revision of Plplot for the Visual Studio 11 generator, including without explicitly disabling fortran. Thanks Alan and Andrew for the fixes. The FindwxWidget.cmake module has a bug meaning it will only ever return the 32 bit version of wxWidget libraries and it will fail (if that's the correct terminology) if these don't exist - which then affects the library as well as the examples. I've reported this as a bug and supplied a patch at http://www.cmake.org/Bug/view.php?id=14642. The patch only fixes visual studio generators. Arjen, if you use gcc, then maybe you would know the appropriate syntax for this generator and might want to create and submit an equivalent gcc patch. The FindwxWidgets.cmake module also doesn't have support for wxWidgets 3.0 in the latest release version. This has already been reported as a bug and a patch submitted and accepted at http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=14587&graph=relation Again related to 64 bit builds - It seems that the VC++ x86 Command line must be used even for 64 bit builds. This again seems to be a CMake bug. I have mentioned this in the bug above. I will see what the response is and submit it as a separate bug if needed. This just leaves the prepending of "-L+" to system libraries needed for wxWidgets. Note that this doesn't actually effect building the libraries, just the exes for the examples etc. I can work round this by disabling D, but maybe this isn't possible for others. I will try to check the nmake generator later today to see if that works. Although, I haven't used it before and I'm not sure I'll have much time today. I'll do my best. On Friday, 13 December 2013, 21:49, Alan W. Irwin <ir...@be...> wrote: The short story is I have decided to put off the release to early next week (if a lot of progress is made over the weekend) or even later in the week. Now here is the longer story about where we stand with this release. @Arjen: I very much appreciate the guidance you have given about the problems Phil has been finding. Here are the Windows issues as I understand them now from what Arjen has said, but please correct this summary if I get something wrong. (1) The "Visual Studio 11" generator (for the VS2012 IDE) is not working correctly. This is likely (see below for my own conclusions confirming that) an inherent CMake bug and nothing to do with PLplot. So according to Arjen's advice we note the issue but do not delay the release because of it. After all, it is not a showstopper for individuals with VS2012 since nmake should always be available to them for building PLplot. (2) Subsequently, Arjen found similar but less severe issues with the "Visual Studio 10" generator (for the VS2010 IDE), but I assume we should treat this the same as (1). (3) Phil has found the following issue which I spotted in the CMake output that he sent for the "Visual Studio 11" generator: CMake Error at cmake/modules/plplot_functions.cmake:210 (list): list sub-command REMOVE_DUPLICATES requires list to be present. Call Stack (most recent call first): cmake/modules/shapelib.cmake:34 (filter_rpath) cmake/modules/plplot.cmake:513 (include) CMakeLists.txt:111 (include) That error message implies none of CMAKE_C_IMPLICIT_LINK_DIRECTORIES, CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES, or CMAKE_FORTRAN_IMPLICIT_LINK_DIRECTORIES are defined which is impossible (!) according to the CMake documentation. My conclusion from this is the "Visual Studio 11" generator is severely broken. Neverthless, I did make the filter_rpath command robust against this unexpected bad result for those variables in revision 12864. (4) Phil has found a really strange -L+ issue where the workaround is to set -DENABLE_d=OFF. I assume that issue is also for the "Visual Studio 11" generator. @Phil: I strongly second Arjen's suggestion that you move to nmake for now. Once we have that working perfectly for you, then we can go back (post-release) to try and figure out what is wrong with VS2012 (which will likely involve CMake bug reports rather than anything to do with PLplot). If you agree this is the right approach, would you please try the "NMake Makefiles" generator as soon as possible, and let us know if (a) there are any cmake issues left for that case, and (b) assuming all is well with the cmake results, does the PLplot build with nmake work and pass all your usual tests? Of course, there are still some uncertainties about the Windows platform until Phil responds to the above request, but my guess from Arjen's good experiences with nmake is that it will work well for Phil as well. IMPORTANT. But if Phil does find nmake issues for his platform, I would view those as release critical so I would be willing to delay the release until you guys figure out whatever that (hypothetical) problem is. As far as I know there are no release-critical Mac OS X issues. Jerry did find a general issue with the test logic that I recently fixed, but my understanding from what he has said is everything else has been working well for him on that platform. Here is the summary of the remaining release-critical issues for the Linux platform (including the reason I have decided to delay the release for at least a few days). I discovered these issues as a result of the option for comprehensive testing of PLplot I enabled last night for the epa_build project. (1) A potential showstopper was segfaults for -dev tk for the combination of Tcl/Tk8.6 and using the stubs version of the Tcl/Tk libraries. I have worked around this issue for this release by switching back to using the ordinary Tcl/Tk libraries by default (the approach we had been using until last month). But using the stubs versions of the Tcl/Tk libraries is highly recommended by the Tcl/Tk developers. They also strongly suggest (as do I) moving from the deprecated Tcl/Tk API we currently use to the recommended Tcl/Tk API. That may solve the segfault issue, but there are obviously a lot of high-priority changes we need to make in the Tcl/Tk bindings and examples post-release. (2) There is a build-system inconsistency about the pkg-config version that is being used. I hope to address that today. (3) The real issue with a release this weekend (assuming nmake is fine for Phil) is I am suddenly at least a couple of days behind the schedule I worked out for this release. For example, I still have plans to do one more complete round of testing via epa_build on Linux and also on MinGW/MSYS/Wine, and there are bound to be some issues to fix especially for the latter platform. So the start of the release process which I had planned for Thursday morning is likely only going to happen Monday morning at the earliest. In sum, there is still some open-ended stuff to do for this release on Linux, MinGW/MSYS/Wine and also possibly MSVC/nmake platforms so it is hard to predict exact timing, but my guess is it going to be at least Monday morning before I start the actual release process and at least Tuesday before I finish that release process. But I will keep you guys informed as the currently large uncertainties gradually disappear about when the release will actually happen. I also am taking this opportunity to publicly thank everybody who has been so heavily testing PLplot these last few days. The fixes that have resulted from that testing have already added greatly to the quality of this forthcoming release! 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-12-14 17:58:31
|
On 2013-12-14 03:08-0800 phil rosenberg wrote: > Hi All > So here is my current status building Plplot with VC++ 2012 and wxWidgets 3.0, for both 32 and 64 bit. > CMake now completes the for the latest revision of Plplot for the Visual Studio 11 generator, including without explicitly disabling fortran. Thanks Alan and Andrew for the fixes. > The FindwxWidget.cmake module has a bug meaning it will only ever return the 32 bit version of wxWidget libraries and it will fail (if that's the correct terminology) if these don't exist - which then affects the library as well as the examples. I've reported this as a bug and supplied a patch at http://www.cmake.org/Bug/view.php?id=14642. The patch only fixes visual studio generators. Arjen, if you use gcc, then maybe you would know the appropriate syntax for this generator and might want to create and submit an equivalent gcc patch. > The FindwxWidgets.cmake module also doesn't have support for wxWidgets 3.0 in the latest release version. This has already been reported as a bug and a patch submitted and accepted at http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=14587&graph=relation @Arjen: After the release when there is more time, I suggest you test (and modify if necessary) Phil's revised FindwxWidget.cmake on all platforms/compilers accessible to you on Windows to ensure there are no side effects of the changes. Then please commit it in cmake/modules so it will immediately benefit all our wxwidgets users on the Windows platforms. > Again related to 64 bit builds - It seems that the VC++ x86 Command line must be used even for 64 bit builds. This again seems to be a CMake bug. I have mentioned this in the bug above. I will see what the response is and submit it as a separate bug if needed. > This just leaves the prepending of "-L+" to system libraries needed for wxWidgets. Note that this doesn't actually effect building the libraries, just the exes for the examples etc. I can work round this by disabling D, but maybe this isn't possible for others. > I will try to check the nmake generator later today to see if that works. Although, I haven't used it before and I'm not sure I'll have much time today. I'll do my best. @Phil: I very much appreciate you making this additional effort for the important nmake case. 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-12-16 09:52:16
|
Hi Alan, Phil, the coming few weeks will of course be littered by all manner of activities which have nothing to do with PLplot, but I will do my best regarding the wxWidgets problem and fix and other open issues. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Saturday, December 14, 2013 6:58 PM > To: Arjen Markus; phil rosenberg > Cc: PLplot development list; Andrew Ross > Subject: Re: Status of the release > > On 2013-12-14 03:08-0800 phil rosenberg wrote: > > > Hi All > > So here is my current status building Plplot with VC++ 2012 and wxWidgets 3.0, > for both 32 and 64 bit. > > > CMake now completes the for the latest revision of Plplot for the > Visual Studio 11 generator, including without explicitly disabling fortran. Thanks Alan > and Andrew for the fixes. > > > The FindwxWidget.cmake module has a bug meaning it will only ever > return the 32 bit version of wxWidget libraries and it will fail (if that's the correct > terminology) if these don't exist - which then affects the library as well as the > examples. I've reported this as a bug and supplied a patch at > http://www.cmake.org/Bug/view.php?id=14642. The patch only fixes visual studio > generators. Arjen, if you use gcc, then maybe you would know the appropriate syntax > for this generator and might want to create and submit an equivalent gcc patch. > > > The FindwxWidgets.cmake module also doesn't have support for > wxWidgets 3.0 in the latest release version. This has already been reported as a bug > and a patch submitted and accepted at > http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=14587&graph=relati > on > > @Arjen: > > After the release when there is more time, I suggest you test (and modify if > necessary) Phil's revised FindwxWidget.cmake on all platforms/compilers accessible > to you on Windows to ensure there are no side effects of the changes. Then please > commit it in cmake/modules so it will immediately benefit all our wxwidgets users on > the Windows platforms. > > > Again related to 64 bit builds - It seems that the VC++ x86 Command > line must be used even for 64 bit builds. This again seems to be a CMake bug. I > have mentioned this in the bug above. I will see what the response is and submit it > as a separate bug if needed. > > > This just leaves the prepending of "-L+" to system libraries needed > for wxWidgets. Note that this doesn't actually effect building the libraries, just the > exes for the examples etc. I can work round this by disabling D, but maybe this isn't > possible for others. > > > I will try to check the nmake generator later today to see if that > works. Although, I haven't used it before and I'm not sure I'll have much time today. > I'll do my best. > > @Phil: I very much appreciate you making this additional effort for the important > nmake case. > > 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-12-14 21:19:30
|
On 2013-12-14 10:58-0800 phil rosenberg wrote: > Hi Alan > Just to confirm, the nmake build seems to be fine. It has reached example 17 as I am writing this with no link errors, so the -L+ problem doesn't exist for this generator. Hi Phil: I am putting this back on list because I think others will be interested in your results. [quoted from your previous post] > Again related to 64 bit builds - It seems that the VC++ x86 Command line must be used even for 64 bit builds. Is this issue gone as well for nmake? If so, it should be written up as a VS2012 bug. I bet the further issue you found indirectly (completely neglecting to set the CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES variables) is gone as well, but to prove that you would have to set up a simple test project, e.g., cmake_minimum_required(VERSION 2.8.12.1 FATAL_ERROR) project(test_c_variable C CXX Fortran) message(STATUS "CMAKE_C_IMPLICIT_LINK_DIRECTORIES = ${CMAKE_C_IMPLICIT_LINK_DIRECTORIES}") message(STATUS "CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES = ${CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES}") message(STATUS "CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES = ${CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES}") The results here (on Linux) for that test are -- CMAKE_C_IMPLICIT_LINK_DIRECTORIES = /usr/lib/gcc/x86_64-linux-gnu/4.7;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib -- CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES = /usr/lib/gcc/x86_64-linux-gnu/4.7;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib -- CMAKE_Fortran_IMPLICIT_LINK_DIRECTORIES = /usr/lib/gcc/x86_64-linux-gnu/4.7;/usr/lib/x86_64-linux-gnu;/usr/lib;/lib/x86_64-linux-gnu;/lib Drop Fortran from the above test if you don't have that compiler. The cmake documentation of CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES implies these variables should be present for every enabled language and every generator. But the case becomes even stronger (and worth a bug report for the VS2012 case) if they are present for nmake, but not for VS2012. How are you doing the testing you referred to above? Do you have MSYS (including bash.exe) installed so that ctest and also the test_noninteractive and test_interactive targets work on Windows or is this some other testing scheme you have set up? 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-12-16 00:45:30
|
On 2013-12-13 13:49-0800 Alan W. Irwin wrote: > In sum, there is still some open-ended stuff to do for this release on > Linux, MinGW/MSYS/Wine and also possibly MSVC/nmake platforms so it is > hard to predict exact timing, but my guess is it going to be at least > Monday morning before I start the actual release process and at least > Tuesday before I finish that release process. But I will keep you > guys informed as the currently large uncertainties gradually disappear > about when the release will actually happen. Well, I knocked off one Linux build-system inconsistency for pkg-config which finally allows the comprehensive tests for the epa_build environment (i.e., cmake options, environment variables, buildtools that have been built, and dependencies that have been built) to finish for the shared library case today. However, there are still problems for the non-dynamic device drivers (where the Tcl/Tk bindings and devices get embedded into libplplotd, but the Tcl/Tk8.6 libraries installed in a special location cannot be found for the installed version of that library because of rpath issues). And the static case and the whole MinGW/MSYS/Wine platform currently remain untested for the epa_build environment. So the release continues to be delayed by issues I have been discovering as a result of trying comprehensive testing for the epa_build environment. 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-12-17 06:58:12
|
It's been one more day of chasing rpath (and other) issues. I was able to obtain a good comprehensive test result for a normal build environment (after some work dealing with some issues that had crept in since I successfully ran this test ~10 days ago), but there continue to be issues for the epa_build environment cases. So the following paragraph is still true.... On 2013-12-15 16:45-0800 Alan W. Irwin wrote: > So the release continues to be delayed by issues I have been > discovering as a result of trying comprehensive testing for the > epa_build environment. IMPORTANT: Also, I have made so many build-system changes since you guys last tested, this is advance notice that later this week after all my tests are done (including the currently non-working or non-tested epa_build environments for both Linux and MinGW/MSYS), I will call on as many of you as have time for it this close to the Christmas season to do one last round of testing on your own platforms/build system environments before I release. The reason this additional testing is important is my recent results show that comprehensive tests can sniff out build-system bugs much better if applied for a wide variety of build environments i.e., cmake options, environment variables, buildtools that have been built, dependencies that have been built, and system libraries that are available. There are a very large number of different build environments even on Linux so it is not realistic to expect testing on just one them is going to be sufficient. In fact, when I recently switched from my usual Linux build environment to three different Linux build environments (my usual one and two different ("build_plplot" and "build_plplot_lite") epa_build build environments, those tests found a whole host of build-system issues I was unaware of before, and which I am currently fixing. If we add in your different Linux build environments and also different build environments on other platforms, the sensitivity of the group of comprehensive tests from all of us becomes even greater. Note in contrast to the need for large amounts of testing for each release cycle, it is also quite important to release in a timely manner. So it's a somewhat arbitrary balancing act between the two needs depending on the release manager's tastes. In my own case, I am going to wait until all my own tests work, and as soon as that happens (now probably Wednesday at the earliest), I will let you know and give you a chance to do some final testing while I take a day or so to go through the release process (version changes, building the website, etc.). Thus, I do hope some of you will be mentally prepared by this advance notice to test on short notice this week when I give the word. 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-12-18 07:29:59
|
On 2013-12-16 22:58-0800 Alan W. Irwin wrote: > IMPORTANT: Also, I have made so many build-system changes since you > guys last tested, this is advance notice that later this week after > all my tests are done (including the currently non-working or > non-tested epa_build environments for both Linux and MinGW/MSYS), I > will call on as many of you as have time for it this close to the > Christmas season to do one last round of testing on your own > platforms/build system environments before I release. > > The reason this additional testing is important is my recent results > show that comprehensive tests can sniff out build-system bugs much > better if applied for a wide variety of build environments i.e., cmake > options, environment variables, buildtools that have been built, > dependencies that have been built, and system libraries that are > available. My three build environments are (1) My normal one which uses Debian Wheezy installed packages for essentially all PLplot dependencies. So for this case, PLplot is full-featured but the buildtools and dependencies tend to be old versions. (2) The "build_plplot_lite" epa_build environment which uses epa_build buildtools results such as Tcl/Tk8.6, epa_build results for many ordinary but minor PLplot dependencies (like shapelib and qhull), but which specifically ignores cairo, qt, and wxwidgets. So for this case, PLplot is not full-featured. (3) The "build_plplot" epa_build environment which uses epa_build buildtools results such as Tcl/Tk8.6 and epa_build results for essentially all ordinary PLplot dependencies (including all the minor ones such as shapelib and qhull, and all major ones, i.e., Qt4, the pango/cairo libraries, and wxwidgets, except for octave. So for this case PLplot is full-featured like in (1), but the dependencies are newer versions that have been build by epa_build rather than system versions. On Linux I have now successfully completed default (where essentially all possible tests are run for the particular build environment) runs of scripts/comprehensive_test.sh both for (1) and (2). However, (3) is currently not working because of a rather nasty dependency mess when attempting to epa_build both pango/cairo and wxwidgets on Unix. The issue is that wxwidgets normally uses the gtk toolkit on Unix so wxwidgets should be built and linked against a consistent version of gtk. But epa_build currently does not supply that (just a consistent pango/cairo subset of gtk). So the resulting epa_build of wxwidgets was linked against some system libraries that are part of the gtk suite of libraries and the epa_build pango/cairo subset of the gtk suite of libraries, and that mixing of inconsistent library versions was causing test errors for wxwidgets in the case of (3) above. I explored the possibilities of using the bare X toolkit and also the motif/lesstif toolkits instead (to force using pure system libraries for the epa_build of wxwidgets), but those wxwidgets epa_builds failed because those toolkits are not unicode aware and PLplot needs a unicode-aware version of wxwidgets. So the only wxwidgets toolkit that we can use on Unix is gtk, and the long-term solution for that case is to epa_build all of the gtk suite of libraries in a consistent way. In principle, that should be completely straightforward since I have all the build data and dependencies for those libraries at my fingertips, but in practice I will wait to implement that until post-release since it will probably take several days to refine those build data so that the many different libraries in the gtk suite all epa_build properly on Linux. In the short term for this release I am going to shut down the epa_build of wxwidgets, and then (3) will end up using the (consistent) system version of wxwidgets, and the wxwidgets-related errors that were stopping (3) from being a success _should_ disappear. Assuming I can get that to work early tomorrow (Wednesday), then my last pre-release step is to get (2) to work on MinGW/MSYS/Wine but the timing of finishing that is still quite uncertain (it could be Wednesday night or several days later) because it has been so long since I have tried the MinGW/MSYS/Wine case. However, I will continue to keep you informed on the timing of this last pre-release work as that timing gradually becomes more certain. 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-12-19 02:54:00
|
On 2013-12-17 23:29-0800 Alan W. Irwin wrote: > (3) The "build_plplot" epa_build environment which uses epa_build > buildtools results such as Tcl/Tk8.6 and epa_build results for > essentially all ordinary PLplot dependencies (including all the minor > ones such as shapelib and qhull, and all major ones, i.e., Qt4, the > pango/cairo libraries, and wxwidgets, except for octave. So for this > case PLplot is full-featured like in (1), but the dependencies are > newer versions that have been build by epa_build rather than system > versions. I finally got (3) to work today by temporarily dropping everything that is wxwidgets related in the epa_build. Post release, I will implement a full epa_build of virtually all components of the GTK stack of libraries which should provide the necessary consistent set of those libraries as dependencies of wxwidgets and thus allow me to reintroduce wxwidgets into epa_build. > My > last pre-release step is to get (2) to work on MinGW/MSYS/Wine but the > timing of finishing that is still quite uncertain (it could be > Wednesday night or several days later) because it has been so long > since I have tried the MinGW/MSYS/Wine case. The above is the remaining step on my agenda before I start the release process. Of course, the caveat about uncertain timing for this step still holds, but I hope to get it done in the next 24 hours. I am pretty sure these tests will turn up a number of epa_build issues that I will want to fix before release, but I doubt there will be many issues turned up for the non-epa_build part of the PLplot source code. Therefore, I think this would be a good opportunity for everybody here to retest in the next 24 hours or so to make sure all the recent non-epa_build changes in PLplot since you last tested have not affected your platform. Of course, such retesting is a "would-be-nice" so you should not concern yourself with such retesting if you don't have time to do it on this extremely short notice. 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-12-18 17:07:01
|
To Andrew, Jerry, Arjen, and Phil: There are some important questions below for you. I need those questions answered for the release notes (README.release) for the forthcoming release. For example, when I am done with my testing, my test summary in README.release will read Comprehensive tests for a complete system build environment were run on 64-bit Debian Wheezy Linux on AMD-64 hardware. Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot components were dropped) epa_build environment were run on 64-bit Debian Wheezy Linux on AMD-64 hardware. Comprehensive tests for a complete epa_build environment were run on 64-bit Debian Wheezy Linux on AMD-64 hardware. Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot components were dropped) epa_build environment were run for 32-bit MinGW/MSYS/Wine on AMD-64 hardware. I need similar tests summaries from all of you that have run tests for this release. I give preliminary (and quite uncertain, see all the question marks) versions below. Please send back the corrected versions of these test summaries. In most cases the question marks should be quite easy to replace with your actual test data. However, the phrase "Limited tests??" is a bit of a special case. It should be replaced by one of "Comprehensive tests" (if you actually ran the scripts/comprehensive_test.sh script), a phrase summarizing the exact test you ran such as "ctest + the test_noninteractive target in the build tree" for intermediate testing, or "Limited tests" for those cases where you actually only did a few tests by hand. @Andrew: Limited tests?? for a complete system build environment were run on 64-bit?? Debian unstable on AMD-64 hardware?? Limited tests?? for a complete system build environment were run on 64-bit Ubuntu version?? on AMD-64 hardware? @Jerry: The Ada subset of the ctest tests were run in the build tree for a limited (what PLplot components were dropped??) build environment on Mac OS X (version??) on AMD-64 hardware?? @Arjen: Limited tests?? for a complete system build environment were run for 64-bit?? Cygwin on Windows (version ??) for AMD-64 hardware?? Limited tests?? for a limited (what PLplot components were dropped??) system build environment were run for 64-bit?? MinGW/MSYS on Windows (version ??) on AMD-64 hardware?? Limited tests?? for a limited (what PLplot components were dropped??) system build environment were run for 64-bit?? MSVC (version??) + Ifort (version??) compilers on 64-bit Windows (version ??) for AMD-64 hardware?? The "NMake Makefiles" generator yielded good results while the "Visual Studio 10" generator appropriate to the VS2010 IDE did not work indicating there are some CMake bugs for that generator that need to be addressed. @Phil: Limited tests?? for a limited (what PLplot components were dropped??) system build environment were run for both 32-bit and 64-bit MSVC (version??) compilers on 64-bit Windows (version ??) for AMD-64 hardware?? The "NMake Makefiles" generator yielded good results while the "Visual Studio 11" generator appropriate to the VS2012 IDE had some issues that could be worked around but which nevertheless indicated there are some CMake bugs for that generator that need to be addressed. The 3.0 version of wxwidgets was tried for these tests but required some CMake patches <available at http://www.cmake.org/Bug/view.php?id=14587 and http://www.cmake.org/Bug/view.php?id=14642> to work. Thanks in advance for your assistance with editing these test summaries. 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: phil r. <phi...@ya...> - 2013-12-18 20:35:04
|
Hi Alan I've never tried the actual test scripts - there was a note on the wiki that said they don't work on Windows and I always assumed they were shell scripts so I wouldn't be able to run them. Anyway, I've noted below what I have actually done, which is really to test that the libraries build and a small amount of use in anger as it were. However, now I have these built with wxWidgets 3.0 I can confirm the bug that Joost described a short while ago with the examples - it looks like only the original window area is ever redrawn. However my own code works fine. Looking at that will have to wait until the new year now I imagine. Anyway modified paragraph below. Feel free to modify further to match the style of the rest of the document. Successful builds were achieved using Visual Studio 2012 on 64 bit Windows 8 with wxWidgets 3.0 (x86 and x64 builds) and Visual Studio 2008 on 32 bit Windows 7 with wxWidgets 2.8 (x86 builds only). In both cases only the C and C++ bindings were built. The "NMake Makefiles" generator with Visual Studio 2012 was also successfully used to build the same configurations. When using wxWidgets 3.0 CMake patches were required and these are available at http://www.cmake.org/Bug/view.php?id=14587 and http://www.cmake.org/Bug/view.php?id=14642. Some problems also exist with the use of Plplot's wxWidgetsApp with wxWidgets 3.0 which were observed in the examples, however plots embedded in wxWidgets apps seem to work fine. With the above patches applied the "NMake Makefiles" generator gave results which built without problems. The "Visual Studio 9 2008" generator with wxWidgets 2.8 also gave results which built without problems. The "Visual Studio 11" and "Visual Studio 11 Win64" generators had some issues which could be worked around but which nevertheless indicated there are some CMake bugs for that generator that need to be addressed. On Wednesday, 18 December 2013, 17:06, Alan W. Irwin <ir...@be...> wrote: To Andrew, Jerry, Arjen, and Phil: There are some important questions below for you. I need those questions answered for the release notes (README.release) for the forthcoming release. For example, when I am done with my testing, my test summary in README.release will read Comprehensive tests for a complete system build environment were run on 64-bit Debian Wheezy Linux on AMD-64 hardware. Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot components were dropped) epa_build environment were run on 64-bit Debian Wheezy Linux on AMD-64 hardware. Comprehensive tests for a complete epa_build environment were run on 64-bit Debian Wheezy Linux on AMD-64 hardware. Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot components were dropped) epa_build environment were run for 32-bit MinGW/MSYS/Wine on AMD-64 hardware. I need similar tests summaries from all of you that have run tests for this release. I give preliminary (and quite uncertain, see all the question marks) versions below. Please send back the corrected versions of these test summaries. In most cases the question marks should be quite easy to replace with your actual test data. However, the phrase "Limited tests??" is a bit of a special case. It should be replaced by one of "Comprehensive tests" (if you actually ran the scripts/comprehensive_test.sh script), a phrase summarizing the exact test you ran such as "ctest + the test_noninteractive target in the build tree" for intermediate testing, or "Limited tests" for those cases where you actually only did a few tests by hand. @Andrew: Limited tests?? for a complete system build environment were run on 64-bit?? Debian unstable on AMD-64 hardware?? Limited tests?? for a complete system build environment were run on 64-bit Ubuntu version?? on AMD-64 hardware? @Jerry: The Ada subset of the ctest tests were run in the build tree for a limited (what PLplot components were dropped??) build environment on Mac OS X (version??) on AMD-64 hardware?? @Arjen: Limited tests?? for a complete system build environment were run for 64-bit?? Cygwin on Windows (version ??) for AMD-64 hardware?? Limited tests?? for a limited (what PLplot components were dropped??) system build environment were run for 64-bit?? MinGW/MSYS on Windows (version ??) on AMD-64 hardware?? Limited tests?? for a limited (what PLplot components were dropped??) system build environment were run for 64-bit?? MSVC (version??) + Ifort (version??) compilers on 64-bit Windows (version ??) for AMD-64 hardware?? The "NMake Makefiles" generator yielded good results while the "Visual Studio 10" generator appropriate to the VS2010 IDE did not work indicating there are some CMake bugs for that generator that need to be addressed. @Phil: Limited tests?? for a limited (what PLplot components were dropped??) system build environment were run for both 32-bit and 64-bit MSVC (version??) compilers on 64-bit Windows (version ??) for AMD-64 hardware?? The "NMake Makefiles" generator yielded good results while the "Visual Studio 11" generator appropriate to the VS2012 IDE had some issues that could be worked around but which nevertheless indicated there are some CMake bugs for that generator that need to be addressed. The 3.0 version of wxwidgets was tried for these tests but required some CMake patches <available at http://www.cmake.org/Bug/view.php?id=14587and http://www.cmake.org/Bug/view.php?id=14642> to work. Thanks in advance for your assistance with editing these test summaries. 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-12-18 22:17:40
|
Hi Phil: Thanks for that paragraph. There are two questions at the end of this concerning the interpretation of that paragraph. On 2013-12-18 12:31-0800 phil rosenberg wrote: > Hi Alan > I've never tried the actual test scripts - there was a note on the wiki that said they don't work on Windows and I always assumed they were shell scripts so I wouldn't be able to run them. Yes, they are essentially bash shell scripts which work fine for both Unix and also the MinGW/MSYS case. So theoretically if you installed MSYS and put it (but not MinGW) on your PATH you should be able to do complete run-time testing of PLplot for the MSVC/nmake case. In practice, however, Arjen tried that last year, and ran into difficulties which he has not been able to figure out so far. If you would like to try this yourself some time after this release, then MSYS is easy to download and install. Just follow the directions at http://sourceforge.net/projects/mingw/files/Installer/mingw-get/ (Note for the Wine case I used an earlier version of the installer they made available last year there, and I haven't tried the recent version they have now.) Typically you obtain a complete install of MinGW + MSYS in about 5 minutes, and the MinGW part of that can be ignored by not putting MinGW on your PATH. > > Anyway, I've noted below what I have actually done, which is really to test that the libraries build and a small amount of use in anger as it were. However, now I have these built with wxWidgets 3.0 I can confirm the bug that Joost described a short while ago with the examples - it looks like only the original window area is ever redrawn. However my own code works fine. Looking at that will have to wait until the new year now I imagine. > > Anyway modified paragraph below. Feel free to modify further to match the style of the rest of the document. > > Successful builds were achieved using Visual Studio 2012 on 64 bit Windows 8 with wxWidgets 3.0 (x86 and x64 builds) and Visual Studio 2008 on 32 bit Windows 7 with wxWidgets 2.8 (x86 builds only). In both cases only the C and C++ bindings were built. The "NMake Makefiles" generator with Visual Studio 2012 was also successfully used to build the same configurations. When using wxWidgets 3.0 CMake patches were required and these are available at http://www.cmake.org/Bug/view.php?id=14587 and http://www.cmake.org/Bug/view.php?id=14642. Some problems also exist with the use of Plplot's wxWidgetsApp with wxWidgets 3.0 which were observed in the examples, however plots embedded in wxWidgets apps seem to work fine. With the above patches applied the "NMake Makefiles" generator gave results which built without problems. The "Visual Studio 9 2008" generator with wxWidgets 2.8 also gave results which built without problems. The "Visual Studio 11" and "Visual Studio 11 Win64" generators had some issues which could be worked around but which nevertheless indicated there are some CMake bugs for that generator that need to be addressed. To help me interpret what you said, here is my understanding of the background (please correct if I have this wrong): The CMake documentation has the following table concerning visual studio generator names and what they actually do: Visual Studio 6 = Generates Visual Studio 6 project files. Visual Studio 7 = Generates Visual Studio .NET 2002 project files. Visual Studio 10 = Generates Visual Studio 10 (2010) project files. Visual Studio 11 = Generates Visual Studio 11 (2012) project files. Visual Studio 12 = Generates Visual Studio 12 (2013) project files. Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 project files. Visual Studio 8 2005 = Generates Visual Studio 8 2005 project files. Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. Furthermore, http://en.wikipedia.org/wiki/Visual_studio says that the Windows Visual Studio IDE includes MSVC (presumably the latest version of that when the IDE version gets released). And now for two questions concerning the interpretation of your paragraph: Does the above background information combined with what you said in your paragraph mean that you used a consistent Visual Studio 12 (2013) IDE (and corresponding MSVC compiler) for all your tests, but for different Visual Studio generators that you mentioned? If so, this implies the Visual Studio 12 (2013) IDE can accept project files written by CMake generators for earlier Visual Studio versions. And for the nmake test can you confirm you used the MSVC compiler associated with the Visual Studio 12 (2013) IDE, but not the IDE itself? (I assume you did not use the IDE since nmake is a command-line tool.) 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: Andrew R. <and...@us...> - 2013-12-18 21:36:04
|
On Wed, Dec 18, 2013 at 09:06:53AM -0800, Alan Irwin wrote: > To Andrew, Jerry, Arjen, and Phil: > > There are some important questions below for you. I need those > questions answered for the release notes (README.release) for the > forthcoming release. > > For example, when I am done with my testing, my test summary > in README.release will read > > Comprehensive tests for a complete system build environment were run > on 64-bit Debian Wheezy Linux on AMD-64 hardware. > > Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot > components were dropped) epa_build environment were run on 64-bit > Debian Wheezy Linux on AMD-64 hardware. > > Comprehensive tests for a complete epa_build environment were run > on 64-bit Debian Wheezy Linux on AMD-64 hardware. > > Comprehensive tests for a limited (qt, cairo, and wxwidgets PLplot > components were dropped) epa_build environment were run for 32-bit > MinGW/MSYS/Wine on AMD-64 hardware. > > I need similar tests summaries from all of you that have run tests for > this release. I give preliminary (and quite uncertain, see all the > question marks) versions below. Please send back the corrected > versions of these test summaries. In most cases the question marks > should be quite easy to replace with your actual test data. However, > the phrase "Limited tests??" is a bit of a special case. It should be > replaced by one of "Comprehensive tests" (if you actually ran the > scripts/comprehensive_test.sh script), a phrase summarizing the exact > test you ran such as "ctest + the test_noninteractive target in the > build tree" for intermediate testing, or "Limited tests" for those > cases where you actually only did a few tests by hand. > > @Andrew: > > Limited tests?? for a complete system build environment were run > on 64-bit?? Debian unstable on AMD-64 hardware?? I ran make test_noninteractive and test_interactive for a complete system build environment on a 64-bit Debian unstable system on AMD-64 hardware. > Limited tests?? for a complete system build environment were run > on 64-bit Ubuntu version?? on AMD-64 hardware? I ran make test_noninteractive and test_interactive for a complete system build environment on a 64-bit Ubuntu Saucy (13.10) system on AMD-64 hardware. I did not get chance to run the tests on 32-bit Debian unstable with AMD-64 hardware (though I can using the same pbuilder setup used to test Debian 64 bit) Andrew |
From: Alan W. I. <ir...@be...> - 2013-12-19 00:56:59
|
On 2013-12-18 21:35-0000 Andrew Ross wrote: > I ran make test_noninteractive and test_interactive for a complete system > build environment on a 64-bit Debian unstable system on AMD-64 hardware. > >> Limited tests?? for a complete system build environment were run >> on 64-bit Ubuntu version?? on AMD-64 hardware? > > I ran make test_noninteractive and test_interactive for a complete system > build environment on a 64-bit Ubuntu Saucy (13.10) system on AMD-64 > hardware. > > I did not get chance to run the tests on 32-bit Debian unstable with > AMD-64 hardware (though I can using the same pbuilder setup used to test > Debian 64 bit) @Andrew: See 2.5 and 2.6 in the test summaries in README.release (revision 12880). @Phil: See 2.7 and 2.8 in the test summaries in README.release (revision 12880). I split your paragraph into two since two different platforms were involved. I had to make what I hope our intelligent guesses when interpreting your original paragraph and disentangling the results for the two platforms so please carefully review those two paragraphs and let me know if you think further changes need to be made. @Arjen and Jerry: I still hope to hear from you guys. 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-12-19 07:55:36
|
Hi Alan, see my remarks below. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > @Arjen: > > Limited tests?? for a complete system build environment were run for 64-bit?? > Cygwin on Windows (version ??) for AMD-64 hardware?? uname -r gives the information: 1.7.27(0.271/5/3) uname -v gives the information: 2013-12-09 11:54 Not sure if that is enough for you. The hardware of the laptop I test on has an Intel Core i7 processor. On Cygwin components I have excluded are: - Ada, D, itcl/itk, Lua, ocaml, octave (I have simply not looked into them yet) - Perl - has to be done via PDL - Java - there does not seem to be a proper Java version for Cygwin, all my attempts to get gcj to work with PLplot failed - wxWidgets - this failed in attempts to build the libraries - cairo (partly) - there is a problem with the wincairo device test_noninteractive gives a clean result > > Limited tests?? for a limited (what PLplot components were dropped??) system build > environment were run for 64-bit?? MinGW/MSYS on Windows (version ??) on AMD- > 64 hardware?? > I use the 32-bits version of MinGW/MSYS on the same laptop. Version number: 2013072300 (as far as I can tell, from the installation manager). I am not using the MSYS environment. For this platform I have Java (not the other ones I listed as excluded above) but no wxWidgets, cairo, Qt, PNG, PDF Only limited tests, as there is no bash interpreter (*). > Limited tests?? for a limited (what PLplot components were dropped??) system build > environment were run for 64-bit?? MSVC (version??) + Ifort (version??) compilers on > 64-bit Windows (version ??) for AMD-64 hardware?? The "NMake Makefiles" > generator yielded good results while the "Visual Studio 10" generator appropriate to > the VS2010 IDE did not work indicating there are some CMake bugs for that > generator that need to be addressed. > I use MSVC/C++ 2010, Intel Fortran 2011 (Intel Parallel Studio XE 2011, as it is officially called) and mainly the nmake-based generators. Limited (manual) testing of the various examples, again because there is no bash interpreter. I do have Java for this platform, but no Qt, wxWidgets, cairo, JPEG/GIF/ PNG As for the Visual Studio generators, yes, my experience with these generators is mixed. This may be due to the management of the dependencies between projects, not quite sure though. 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-12-19 09:06:43
|
On 2013-12-19 07:55-0000 Arjen Markus wrote: > Hi Alan, > > see my remarks below. > > Regards, > > Arjen > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> >> @Arjen: >> >> Limited tests?? for a complete system build environment were run for 64-bit?? >> Cygwin on Windows (version ??) for AMD-64 hardware?? Hi Arjen: Thanks for your replies on the degree of testing and what components of PLplot you tested on your different Windows platforms. That's going to be a big help to users. > The hardware of the laptop I test on has an Intel Core i7 processor. That information is useful as well. It appears from web sources that the Intel Core i7 processor you use is 64-bit. Intel are quite coy about labelling their 64-capabilities because their Itanium 64-bit "IA-64" processor was a huge technological and marketing failure so they ended up copying AMD's 64-bit design for their modern hardware. They referred to that design by several names before finally settling on "Intel 64". But AMD called that 64-bit design AMD64. Since they were first with that design, "AMD64" is the term I will use to refer to your hardware (and virtually everyone else here who did tests). There is some additional information I need as well if it is straightforward for you to figure it out. * Version of the underlying Windows OS (e.g., Windows Vista, Windows 7, or Windows 8) for all three of your platforms (Cygwin, MinGW, and MSVC). * Whether that OS is a 32-bit version or a 64-bit version. * Whether Cygwin is the 32-bit version or the 64-bit version * gcc version for your Cygwin platform. The command "gcc --version" should help you figure that out for that platform. * MinGW version for your pure MinGW platform. The command "gcc --version" should help you figure that out for that platform. 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-12-19 10:55:13
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > Thanks for your replies on the degree of testing and what components of PLplot you > tested on your different Windows platforms. That's going to be a big help to users. > > > The hardware of the laptop I test on has an Intel Core i7 processor. > > That information is useful as well. It appears from web sources that the Intel Core i7 > processor you use is 64-bit. Intel are quite coy about labelling their 64-capabilities > because their Itanium 64-bit "IA-64" processor was a huge technological and > marketing failure so they ended up copying AMD's 64-bit design for their modern > hardware. > They referred to that design by several names before finally settling on "Intel 64". > But AMD called that 64-bit design AMD64. Since they were first with that design, > "AMD64" is the term I will use to refer to your hardware (and virtually everyone else > here who did tests). > Ah, that does explain a lot - there are loads of names for "64-bits" platforms (AMD64, Intel 64, x86_64, x64, IA64 to name the ones I am aware of). Well, the machine has a sticker "Intel inside CORE i7" and I know my Windows OS is 64-bits. The MicroSoft compiler suite has confusing names too, referring to AMD64 for instance. > There is some additional information I need as well if it is straightforward for you to > figure it out. > > * Version of the underlying Windows OS (e.g., Windows Vista, Windows 7, or > Windows 8) for all three of your platforms (Cygwin, MinGW, and MSVC). > Here it is: Windows 7, 64-bits, service pack 1 (well, actually Windows version 6.1, Windows mode 7 SP1, but that usually referred to as Windows 7) I use the same Windows version for all my testing. > * Whether that OS is a 32-bit version or a 64-bit version. > 64 bits > * Whether Cygwin is the 32-bit version or the 64-bit version > 64 bits > * gcc version for your Cygwin platform. The command "gcc --version" should help > you figure that out for that platform. > GCC 4.8.2 > * MinGW version for your pure MinGW platform. The command "gcc --version" > should help you figure that out for that platform. > For MinGW I use GCC 4.5.2 as well as GCC 4.7.0, as the GNU compiler is less intimately connected to the working environment. The MinGW installation is 32-bits. 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: Andrew R. <and...@us...> - 2013-12-19 13:10:41
|
I plan to try the comprehensive test script for my Debian based configurations later. In the meantime I've been trying to build plplot on a CentOS 5.10 machine at work. This is old software now and I expected problems. I also have no root access so have to work with what's there. I build only cmake from scratch then tried to build plplot. Many drivers / bindings were disabled anyway since components were missing from the system. Bugs I encountered were [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined library unit plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)" plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)" plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)" plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on "Ada.Numerics.Long_Real_Arrays (spec)" make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1 make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o Linking C executable pltek ../src/libplplotd.so.12.0.0: undefined reference to `cairo_ps_surface_set_eps' ../src/libplplotd.so.12.0.0: undefined reference to `pango_layout_get_baseline' collect2: ld returned 1 exit status make[2]: *** [utils/pltek] Error 1 make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2 This was built without dynamic drivers (relevant lib missing) and so cairo driver was compiled into plplot. This looks to me like a linking issue in plplot, possible due to old version of linker since Alan hasn't reported it for his test? Anyway, I disabled the cairo drivers and proceeded. [ 32%] Generating plplot/examples/x00.class ---------- 1. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java (at line 29) import static plplot.core.plplotjavacConstants.*; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax error, static imports are only available if source level is 5.0 ---------- 2. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java (at line 56) pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); ^^^^^^^^^^^^^ PL_PARSE_FULL cannot be resolved ---------- 3. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java (at line 56) pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); ^^^^^^^^^^^^^^^^^^ PL_PARSE_NOPROGRAM cannot be resolved ---------- 3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class] Error 255 make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2 make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2 This looks like a problem with an old version of javac. I might be able to fix this by setting the source level, but I just disabled java and continued. After all this I ended up with just C / C++ / F95 bindings and with a minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however pass make test_interactive and make test_noninteractive. On the plus side I spotted a bug with plcolorbar in the C++ bindings. Not sure why this hadn't been triggered with newer versions of gcc. I have also tried epa_build_lite. I got as far as building libharu and the build failed with Building C object src/CMakeFiles/hpdf_static.dir/hpdf_string.o cd /tmp/build_plplot/build_dir-linux/epa_build/Build/build_libharu/src && /usr/bin /cc -O3 -fvisibility=hidden -Wuninitialized -I/tmp/build_plplot/build_dir-linux /epa_build/Source/build_libharu/include -I/tmp/build_plplot/build_dir-linux/epa_bu ild/Build/build_libharu/include -o CMakeFiles/hpdf_static.dir/hpdf_string.o - c /tmp/build_plplot/build_dir-linux/epa_build/Source/build_libharu/src/hpdf_string .c /usr/local/lib/libz.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status gmake[6]: *** [src/libhpdf.so.0.0.0] Error 1 Note this is a static build, but trying to link in the shared version of libz. I think this is because there is no libz.a installed, however cmake didn't spot this corner case. Manually massaging the linker options allowed me to continue, however for some reason the header file hpdf_pdfa.h is not installed (this is only required in the static case) and so any code using hpdf.h will fail. Copying the header into the install tree got me a bit further. I then had to muck about to disable ada and java to get the build to complete and to install (p.s. Alan: How do I pass cmake options to the plplot build when using epa? I went in and reran cmake by hand - not ideal). I then tried the cmake based tests in the install tree. make test_noninteractive failed becauase the epa built itcl / itk libraries were not found. There is no rpath information for these, even though the other libraries are fine. Setting LD_LIBRARY_PATH allowed me to continue and then the examples ran fine. Tried to run build_plplot which fails straight away with 1%] Performing download step (verify and extract) for 'build_qt4_lite' cd /tmp/build_plplot/build_dir-linux/epa_build/Source && /nfs/see-archive-15_a58/l ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P /tmp/buil d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak e -- verifying file... file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz' CMake Error at /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve rify-build_qt4_lite.cmake:5 (file): file MD5 failed to read file "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No such file or directory Looks like this points to a file on Alan's hard disk rather than trying to download. You probably want to comment out the temporary debugging line before the release. I'll commit that change myself now. Having done that the build is now chugging away. More later... So, in conclusion, I can build at least a basic version of plplot on this old CentOS system. With the lite version of epa_build I can include tcl / tk as well as adding some extra drivers (ntk, tk, tkwin, pdf). I'm still testing build_plplot and will report back on that later. I must say, if we can iron out the bugs, this will be a useful easy way of building plplot on this system where I don't have root access to install new system packages. Thanks Alan! Andrew |
From: Andrew R. <and...@us...> - 2013-12-19 13:45:08
|
On Thu, Dec 19, 2013 at 01:10:25PM +0000, Andrew Ross wrote: > > Tried to run build_plplot which fails straight away with > > 1%] Performing download step (verify and extract) for 'build_qt4_lite' > cd /tmp/build_plplot/build_dir-linux/epa_build/Source && /nfs/see-archive-15_a58/l > ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P /tmp/buil > d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak > e > -- verifying file... > file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz' > CMake Error at /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve > rify-build_qt4_lite.cmake:5 (file): > file MD5 failed to read file > "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No > such file or directory > > Looks like this points to a file on Alan's hard disk rather than trying > to download. You probably want to comment out the temporary debugging line > before the release. I'll commit that change myself now. Having done that the > build is now chugging away. More later... > OK. So this fails for yelp-xsl because the source is compressed as a .xh file and my version of tar doesn't support this option. Looks like this will rule out the gnome stuff. I'm not sure how to fix / disable this so this is likely to be the extent of my epa testing for now, unless I find time to build a new version of tar. Andrew |
From: Alan W. I. <ir...@be...> - 2013-12-19 18:25:27
|
Hi Andrew: Thanks for this very interesting test. More below. On 2013-12-19 13:10-0000 Andrew Ross wrote: > > I plan to try the comprehensive test script for my Debian based configurations > later. In the meantime I've been trying to build plplot on a CentOS 5.10 > machine at work. This is old software now and I expected problems. I also > have no root access so have to work with what's there. > > I build only cmake from scratch then tried to build plplot. > > Many drivers / bindings were disabled anyway since components were missing > from the system. Bugs I encountered were > > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined library unit > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)" > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)" > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)" > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on "Ada.Numerics.Long_Real_Arrays (spec)" > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1 > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 > > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued > > 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o > Linking C executable pltek > ../src/libplplotd.so.12.0.0: undefined reference to `cairo_ps_surface_set_eps' > ../src/libplplotd.so.12.0.0: undefined reference to `pango_layout_get_baseline' > collect2: ld returned 1 exit status > make[2]: *** [utils/pltek] Error 1 > make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2 > > This was built without dynamic drivers (relevant lib missing) and so > cairo driver was compiled into plplot. This looks to me like a linking > issue in plplot, possible due to old version of linker since Alan hasn't > reported it for his test? I am pretty sure the problem is the old version of cairo. libplplotd needs cairo_ps_surface_set_eps, etc., but it looks like the old version of cairo on that system does not supply it. > > Anyway, I disabled the cairo drivers and proceeded. > > [ 32%] Generating plplot/examples/x00.class > ---------- > 1. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > (at line 29) > import static plplot.core.plplotjavacConstants.*; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Syntax error, static imports are only available if source level is 5.0 > ---------- > 2. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > (at line 56) > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); > ^^^^^^^^^^^^^ > PL_PARSE_FULL cannot be resolved > ---------- > 3. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > (at line 56) > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); > ^^^^^^^^^^^^^^^^^^ > PL_PARSE_NOPROGRAM cannot be resolved > ---------- > 3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class] Error 255 > make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2 > make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2 > > This looks like a problem with an old version of javac. I might be able > to fix this by setting the source level, but I just disabled java and > continued. > > After all this I ended up with just C / C++ / F95 bindings and with a > minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however > pass make test_interactive and make test_noninteractive. That's an extremely useful test result for enterprise Linux. Can you write it up in the same style as the rest of the test results in README.release? > On the plus side I spotted a bug with plcolorbar in the C++ bindings. > Not sure why this hadn't been triggered with newer versions of gcc. I am surprised also that slipped through our previous tests, but I am very glad you found it. > > I have also tried epa_build_lite. I got as far as building libharu and > the build failed with > > Building C object src/CMakeFiles/hpdf_static.dir/hpdf_string.o > cd /tmp/build_plplot/build_dir-linux/epa_build/Build/build_libharu/src && /usr/bin > /cc -O3 -fvisibility=hidden -Wuninitialized -I/tmp/build_plplot/build_dir-linux > /epa_build/Source/build_libharu/include -I/tmp/build_plplot/build_dir-linux/epa_bu > ild/Build/build_libharu/include -o CMakeFiles/hpdf_static.dir/hpdf_string.o - > c /tmp/build_plplot/build_dir-linux/epa_build/Source/build_libharu/src/hpdf_string > .c > /usr/local/lib/libz.so: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > gmake[6]: *** [src/libhpdf.so.0.0.0] Error 1 > > Note this is a static build, but trying to link in the shared version of > libz. I think this is because there is no libz.a installed, however > cmake didn't spot this corner case. Manually massaging the linker > options allowed me to continue, however for some reason the header file > hpdf_pdfa.h is not installed (this is only required in the static case) > and so any code using hpdf.h will fail. Copying the header into the > install tree got me a bit further. So far I have only tested epa_build for shared builds, and I never particularly intended to try it with static builds which are always more tricky. So at least for now, I suggest you switch to shared builds. > I then had to muck about to disable ada and java to get the build to complete > and to install (p.s. Alan: How do I pass cmake options to the plplot build when > using epa? I went in and reran cmake by hand - not ideal). Please go ahead and start making changes in epa_build to suit your needs. If it is something simple (like below) feel free to commit it, but if it is something more complicated that potentially might mess up my testing today, I would appreciate you holding off until later to actually do the commit. To implement the present feature request, note that plplot and plplot_lite invoke cmake as follows: CONFIGURE_COMMAND ${ENV_EXECUTABLE} PATH=${EPA_PATH} "CFLAGS=${CFLAGS}" "CXXFLAGS=${CXXFLAGS}" "FFLAGS=${FFLAGS}" ${EPA_CMAKE_COMMAND} -DBUILD_TEST=ON ${cmake_args} ${EPA_BASE}/Source/build_${PACKAGE} where ${cmake_args} is a list of cmake arguments that are defined differently for plplot and plplot_lite, and EPA_CMAKE_COMMAND includes the generator and prefix (see the top-level CMakeLists.txt). I suggest you replace ${cmake_args} above (in both plplot and plplot_lite) by ${cmake_args} ${PLPLOT_USER_cmake_args} where normally PLPLOT_USER_cmake_args is not defined, but in your case you could define it on the cmake command line as -DPLPLOT_USER_cmake_args:STRING="-DENABLE_java=OFF;-DENABLE_ada=OFF;-DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON" (Note how the list of cmake options masquerades as a semicolon-separated series of cmake options). In other words, a minor change to plplot/CMakeLists.txt and plplot_lite/CMakeLists.txt plus invoking cmake for epa_build with the above option should implement your feature request. > > I then tried the cmake based tests in the install tree. > > make test_noninteractive failed becauase the epa built itcl / itk > libraries were not found. There is no rpath information for these, > even though the other libraries are fine. Setting LD_LIBRARY_PATH > allowed me to continue and then the examples ran fine. The PLplot build system does specifically set and use RPATH variables for the Tcl and Tk libraries. If those are empty, that is because somehow they have been set to system locations which are filtered out to nothing by design (since you never want rpath to point to system locations) rather than the desired epa_build buildtools location. I suspect you might not have followed the directions in README with regard to the epa_build of buildtools and setting up your epa_build environment by sourcing a version of setup/setup_linux that has been tailored to your own particular locations for everything. Anyhow, when I follow those directions here, I get the following RPATH results: -- TCL_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib -- TCL_TK_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib -- TCL_TK_ITCL_ITK_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib;/home/wine/newstart/build_script/install-linux_buildtools/lib/itcl3.4;/home/wine/newstart/build_script/install-linux_buildtools/lib/itk3.3 If you don't get lines similar to the above, then those variables have been emptied because they point to the system locations as explained above. The above variables are used appropriately in the PLplot build system so at least for my case is not necessary for me to set LD_LIBRARY_PATH. > > Tried to run build_plplot which fails straight away with > > 1%] Performing download step (verify and extract) for 'build_qt4_lite' > cd /tmp/build_plplot/build_dir-linux/epa_build/Source && /nfs/see-archive-15_a58/l > ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P /tmp/buil > d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak > e > -- verifying file... > file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz' > CMake Error at /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve > rify-build_qt4_lite.cmake:5 (file): > file MD5 failed to read file > "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No > such file or directory > > Looks like this points to a file on Alan's hard disk rather than trying > to download. You probably want to comment out the temporary debugging line > before the release. I'll commit that change myself now. > Having done that the > build is now chugging away. More later... Thanks for spotting and fixing that issue and also giving epa_build a try on CentOS 5.10. More later in response to your finished epa_build results. 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-12-19 19:20:08
|
On 2013-12-19 13:44-0000 Andrew Ross wrote: > On Thu, Dec 19, 2013 at 01:10:25PM +0000, Andrew Ross wrote: >> >> Tried to run build_plplot which fails straight away with >> >> 1%] Performing download step (verify and extract) for 'build_qt4_lite' >> cd /tmp/build_plplot/build_dir-linux/epa_build/Source && /nfs/see-archive-15_a58/l >> ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P /tmp/buil >> d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak >> e >> -- verifying file... >> file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz' >> CMake Error at /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve >> rify-build_qt4_lite.cmake:5 (file): >> file MD5 failed to read file >> "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No >> such file or directory >> >> Looks like this points to a file on Alan's hard disk rather than trying >> to download. You probably want to comment out the temporary debugging line >> before the release. I'll commit that change myself now. Having done that the >> build is now chugging away. More later... >> > > OK. So this fails for yelp-xsl because the source is compressed as a .xh > file and my version of tar doesn't support this option. Looks like this > will rule out the gnome stuff. I'm not sure how to fix / disable this so > this is likely to be the extent of my epa testing for now, unless I find > time to build a new version of tar. I believe I have now fixed that issue with revision 12888. And since you are currently failing on yelp-xsl, that implies that build_plplot_lite (which does not depend on yelp) finished without issues for you, and you went on to try build_plplot (which does depend on yelp indirectly via the pango dependencies). Your results for epa_build on CentOS are extremely encouraging so far, and I am glad to hear they have already been a practical help for you on that platform. 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-12-19 20:22:26
|
On 2013-12-19 10:55-0000 Arjen Markus wrote: > Hi Alan, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> [...]There is some additional information I need as well if it is straightforward for you to >> figure it out. >> >> * Version of the underlying Windows OS (e.g., Windows Vista, Windows 7, or >> Windows 8) for all three of your platforms (Cygwin, MinGW, and MSVC). >> > > Here it is: > Windows 7, 64-bits, service pack 1 (well, actually Windows version 6.1, Windows mode 7 SP1, > but that usually referred to as Windows 7) > > I use the same Windows version for all my testing. > >> * Whether that OS is a 32-bit version or a 64-bit version. >> > > 64 bits > >> * Whether Cygwin is the 32-bit version or the 64-bit version >> > > 64 bits > >> * gcc version for your Cygwin platform. The command "gcc --version" should help >> you figure that out for that platform. >> > > GCC 4.8.2 > >> * MinGW version for your pure MinGW platform. The command "gcc --version" >> should help you figure that out for that platform. >> > > For MinGW I use GCC 4.5.2 as well as GCC 4.7.0, as the GNU compiler is less intimately > connected to the working environment. > > The MinGW installation is 32-bits. Hi Arjen: Thanks for this information. I have attempted to incorporate the information above and everything else you have said about your three different test platforms in revision 12889 of README.release. Please carefully review that material and edit it if necessary. 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: Jerry <lan...@qw...> - 2013-12-19 20:48:37
|
On Dec 19, 2013, at 6:10 AM, Andrew Ross <and...@us...> wrote: > > I plan to try the comprehensive test script for my Debian based configurations > later. In the meantime I've been trying to build plplot on a CentOS 5.10 > machine at work. This is old software now and I expected problems. I also > have no root access so have to work with what's there. > > I build only cmake from scratch then tried to build plplot. > > Many drivers / bindings were disabled anyway since components were missing > from the system. Bugs I encountered were > > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined library unit > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)" > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)" > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)" > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on "Ada.Numerics.Long_Real_Arrays (spec)" > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1 > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 > > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued This is my bad. In Ada 2005 (which I have in the distant past incorrectly called Ada 2007), there was a new numerics annex added which includes type declarations for vectors and matrices along with operations on them, in Ada.Numerics.Long_Real_Arrays. For the PLplot bindings, I did not want to force users to use Ada 2005 but to get by with Ada 95. However, I wanted to make using the new feature available as an option. Since Ada has no switches, the only way to do this that I could figure out was to do some minor commenting in PLplot_Auxiliary.ads. For my personal use, I always edit this file to use the new numerics annex, so obviously I forgot to revert this file before some recent commit. It was bound to happen sometime. So I've corrected the file and now the Ada bindings should compile once again on older Ada compilers. Sorry for the problem. Jerry > > 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o > Linking C executable pltek > ../src/libplplotd.so.12.0.0: undefined reference to `cairo_ps_surface_set_eps' > ../src/libplplotd.so.12.0.0: undefined reference to `pango_layout_get_baseline' > collect2: ld returned 1 exit status > make[2]: *** [utils/pltek] Error 1 > make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2 > > This was built without dynamic drivers (relevant lib missing) and so > cairo driver was compiled into plplot. This looks to me like a linking > issue in plplot, possible due to old version of linker since Alan hasn't > reported it for his test? > > Anyway, I disabled the cairo drivers and proceeded. > > [ 32%] Generating plplot/examples/x00.class > ---------- > 1. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > (at line 29) > import static plplot.core.plplotjavacConstants.*; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Syntax error, static imports are only available if source level is 5.0 > ---------- > 2. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > (at line 56) > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); > ^^^^^^^^^^^^^ > PL_PARSE_FULL cannot be resolved > ---------- > 3. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > (at line 56) > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); > ^^^^^^^^^^^^^^^^^^ > PL_PARSE_NOPROGRAM cannot be resolved > ---------- > 3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class] Error 255 > make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2 > make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2 > > This looks like a problem with an old version of javac. I might be able > to fix this by setting the source level, but I just disabled java and > continued. > > After all this I ended up with just C / C++ / F95 bindings and with a > minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however > pass make test_interactive and make test_noninteractive. > > On the plus side I spotted a bug with plcolorbar in the C++ bindings. > Not sure why this hadn't been triggered with newer versions of gcc. > > I have also tried epa_build_lite. I got as far as building libharu and > the build failed with > > Building C object src/CMakeFiles/hpdf_static.dir/hpdf_string.o > cd /tmp/build_plplot/build_dir-linux/epa_build/Build/build_libharu/src && /usr/bin > /cc -O3 -fvisibility=hidden -Wuninitialized -I/tmp/build_plplot/build_dir-linux > /epa_build/Source/build_libharu/include -I/tmp/build_plplot/build_dir-linux/epa_bu > ild/Build/build_libharu/include -o CMakeFiles/hpdf_static.dir/hpdf_string.o - > c /tmp/build_plplot/build_dir-linux/epa_build/Source/build_libharu/src/hpdf_string > .c > /usr/local/lib/libz.so: could not read symbols: File in wrong format > collect2: ld returned 1 exit status > gmake[6]: *** [src/libhpdf.so.0.0.0] Error 1 > > Note this is a static build, but trying to link in the shared version of > libz. I think this is because there is no libz.a installed, however > cmake didn't spot this corner case. Manually massaging the linker > options allowed me to continue, however for some reason the header file > hpdf_pdfa.h is not installed (this is only required in the static case) > and so any code using hpdf.h will fail. Copying the header into the > install tree got me a bit further. > > I then had to muck about to disable ada and java to get the build to complete > and to install (p.s. Alan: How do I pass cmake options to the plplot build when > using epa? I went in and reran cmake by hand - not ideal). > > I then tried the cmake based tests in the install tree. > > make test_noninteractive failed becauase the epa built itcl / itk > libraries were not found. There is no rpath information for these, > even though the other libraries are fine. Setting LD_LIBRARY_PATH > allowed me to continue and then the examples ran fine. > > Tried to run build_plplot which fails straight away with > > 1%] Performing download step (verify and extract) for 'build_qt4_lite' > cd /tmp/build_plplot/build_dir-linux/epa_build/Source && /nfs/see-archive-15_a58/l > ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P /tmp/buil > d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak > e > -- verifying file... > file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz' > CMake Error at /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve > rify-build_qt4_lite.cmake:5 (file): > file MD5 failed to read file > "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No > such file or directory > > Looks like this points to a file on Alan's hard disk rather than trying > to download. You probably want to comment out the temporary debugging line > before the release. I'll commit that change myself now. Having done that the > build is now chugging away. More later... > > So, in conclusion, I can build at least a basic version of plplot on > this old CentOS system. With the lite version of epa_build I can > include tcl / tk as well as adding some extra drivers (ntk, tk, tkwin, > pdf). I'm still testing build_plplot and will report back on that later. > > I must say, if we can iron out the bugs, this will be a useful easy way of > building plplot on this system where I don't have root access to install > new system packages. Thanks Alan! > > Andrew > |
From: Andrew R. <and...@us...> - 2013-12-19 23:06:17
|
On Thu, Dec 19, 2013 at 01:48:31PM -0700, Jerry wrote: > > On Dec 19, 2013, at 6:10 AM, Andrew Ross <and...@us...> wrote: > > > > > I plan to try the comprehensive test script for my Debian based configurations > > later. In the meantime I've been trying to build plplot on a CentOS 5.10 > > machine at work. This is old software now and I expected problems. I also > > have no root access so have to work with what's there. > > > > I build only cmake from scratch then tried to build plplot. > > > > Many drivers / bindings were disabled anyway since components were missing > > from the system. Bugs I encountered were > > > > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o > > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined library unit > > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)" > > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)" > > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)" > > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on "Ada.Numerics.Long_Real_Arrays (spec)" > > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1 > > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 > > > > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued > > This is my bad. In Ada 2005 (which I have in the distant past incorrectly called Ada 2007), there was a new numerics annex added which includes type declarations for vectors and matrices along with operations on them, in Ada.Numerics.Long_Real_Arrays. For the PLplot bindings, I did not want to force users to use Ada 2005 but to get by with Ada 95. However, I wanted to make using the new feature available as an option. Since Ada has no switches, the only way to do this that I could figure out was to do some minor commenting in PLplot_Auxiliary.ads. For my personal use, I always edit this file to use the new numerics annex, so obviously I forgot to revert this file before some recent commit. It was bound to happen sometime. So I've corrected the file and now the Ada bindings should compile once again on older Ada compilers. > > Sorry for the problem. Jerry, Thanks for the quick fix! Andrew |
From: Andrew R. <and...@us...> - 2013-12-19 22:26:27
|
More responses below. On Thu, Dec 19, 2013 at 10:25:19AM -0800, Alan Irwin wrote: > Hi Andrew: > > Thanks for this very interesting test. More below. > > On 2013-12-19 13:10-0000 Andrew Ross wrote: > > > > > I plan to try the comprehensive test script for my Debian based configurations > > later. In the meantime I've been trying to build plplot on a CentOS 5.10 > > machine at work. This is old software now and I expected problems. I also > > have no root access so have to work with what's there. > > > > I build only cmake from scratch then tried to build plplot. > > > > Many drivers / bindings were disabled anyway since components were missing > > from the system. Bugs I encountered were > > > > [ 18%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.o > > plplot.ads:24:05: "Ada.Numerics.Long_Real_Arrays" is not a predefined library unit > > plplot.ads:24:05: "Plplot (body)" depends on "Plplot (spec)" > > plplot.ads:24:05: "Plplot (spec)" depends on "Plplot_Thin (spec)" > > plplot.ads:24:05: "Plplot_Thin (spec)" depends on "Plplot_Auxiliary (spec)" > > plplot.ads:24:05: "Plplot_Auxiliary (spec)" depends on "Ada.Numerics.Long_Real_Arrays (spec)" > > make[2]: *** [bindings/ada/CMakeFiles/plplotadad.dir/plplot.o] Error 1 > > make[1]: *** [bindings/ada/CMakeFiles/plplotadad.dir/all] Error 2 > > > > Old version of gnat (4.1.2) probably the cause. I disabled Ada and continued > > > > 25%] Building C object utils/CMakeFiles/pltek.dir/pltek.c.o > > Linking C executable pltek > > ../src/libplplotd.so.12.0.0: undefined reference to `cairo_ps_surface_set_eps' > > ../src/libplplotd.so.12.0.0: undefined reference to `pango_layout_get_baseline' > > collect2: ld returned 1 exit status > > make[2]: *** [utils/pltek] Error 1 > > make[1]: *** [utils/CMakeFiles/pltek.dir/all] Error 2 > > > > This was built without dynamic drivers (relevant lib missing) and so > > cairo driver was compiled into plplot. This looks to me like a linking > > issue in plplot, possible due to old version of linker since Alan hasn't > > reported it for his test? > > I am pretty sure the problem is the old version of cairo. libplplotd needs > cairo_ps_surface_set_eps, etc., but it looks like the old version of > cairo on that system does not supply it. That sounds plausible. It may be worth a version check somewhere, but given this is a pretty old version of cairo, I suspect not. > > Anyway, I disabled the cairo drivers and proceeded. > > > > [ 32%] Generating plplot/examples/x00.class > > ---------- > > 1. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > > (at line 29) > > import static plplot.core.plplotjavacConstants.*; > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Syntax error, static imports are only available if source level is 5.0 > > ---------- > > 2. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > > (at line 56) > > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); > > ^^^^^^^^^^^^^ > > PL_PARSE_FULL cannot be resolved > > ---------- > > 3. ERROR in /nfs/see-fs-02_users/lecanr/colpex_archive/lecanr/software/plplot/plplot/examples/java/x00.java > > (at line 56) > > pls.parseopts( args, PL_PARSE_FULL | PL_PARSE_NOPROGRAM ); > > ^^^^^^^^^^^^^^^^^^ > > PL_PARSE_NOPROGRAM cannot be resolved > > ---------- > > 3 problems (3 errors)make[3]: *** [examples/java/plplot/examples/x00.class] Error 255 > > make[2]: *** [examples/java/CMakeFiles/plplot_examples.dir/all] Error 2 > > make[1]: *** [examples/CMakeFiles/test_noninteractive.dir/rule] Error 2 > > > > This looks like a problem with an old version of javac. I might be able > > to fix this by setting the source level, but I just disabled java and > > continued. > > > > After all this I ended up with just C / C++ / F95 bindings and with a > > minimal set of drivers (mem, null, psc, svg, xfig, xwin). It did however > > pass make test_interactive and make test_noninteractive. > > That's an extremely useful test result for enterprise Linux. Can you > write it up in the same style as the rest of the test results in > README.release? Will do. > > On the plus side I spotted a bug with plcolorbar in the C++ bindings. > > Not sure why this hadn't been triggered with newer versions of gcc. > > I am surprised also that slipped through our previous tests, but I am > very glad you found it. > > > > > I have also tried epa_build_lite. I got as far as building libharu and > > the build failed with > > > > Building C object src/CMakeFiles/hpdf_static.dir/hpdf_string.o > > cd /tmp/build_plplot/build_dir-linux/epa_build/Build/build_libharu/src && /usr/bin > > /cc -O3 -fvisibility=hidden -Wuninitialized -I/tmp/build_plplot/build_dir-linux > > /epa_build/Source/build_libharu/include -I/tmp/build_plplot/build_dir-linux/epa_bu > > ild/Build/build_libharu/include -o CMakeFiles/hpdf_static.dir/hpdf_string.o - > > c /tmp/build_plplot/build_dir-linux/epa_build/Source/build_libharu/src/hpdf_string > > .c > > /usr/local/lib/libz.so: could not read symbols: File in wrong format > > collect2: ld returned 1 exit status > > gmake[6]: *** [src/libhpdf.so.0.0.0] Error 1 > > > > Note this is a static build, but trying to link in the shared version of > > libz. I think this is because there is no libz.a installed, however > > cmake didn't spot this corner case. Manually massaging the linker > > options allowed me to continue, however for some reason the header file > > hpdf_pdfa.h is not installed (this is only required in the static case) > > and so any code using hpdf.h will fail. Copying the header into the > > install tree got me a bit further. > > So far I have only tested epa_build for shared builds, and I never > particularly intended to try it with static builds which are always > more tricky. So at least for now, I suggest you switch to shared > builds. Cmake chose to build a static library, not me, so I assume something was missing for building shared versions. Cmake finds.so versions of the libraries when performing the library checks. All these then get successfully change to -l flags, except in this case libz.so. By changing all references to libz.so in CMakeCache.txt to point to another directory with a full copy (.so + .a files) I got everything to "just work". From this I conclude that static libraries would work as long as there is both a shared and static version of the library present. > > I then had to muck about to disable ada and java to get the build to complete > > and to install (p.s. Alan: How do I pass cmake options to the plplot build when > > using epa? I went in and reran cmake by hand - not ideal). > > Please go ahead and start making changes in epa_build to suit your > needs. If it is something simple (like below) feel free to commit > it, but if it is something more complicated that potentially might mess up my > testing today, I would appreciate you holding off until later to > actually do the commit. No problem. I'll wait until post-release now I think. > To implement the present feature request, note that plplot > and plplot_lite invoke cmake as follows: > > CONFIGURE_COMMAND ${ENV_EXECUTABLE} PATH=${EPA_PATH} > "CFLAGS=${CFLAGS}" "CXXFLAGS=${CXXFLAGS}" "FFLAGS=${FFLAGS}" > ${EPA_CMAKE_COMMAND} -DBUILD_TEST=ON ${cmake_args} > ${EPA_BASE}/Source/build_${PACKAGE} > > where ${cmake_args} is a list of cmake arguments that are defined > differently for plplot and plplot_lite, and > EPA_CMAKE_COMMAND includes the generator and prefix (see the > top-level CMakeLists.txt). > > I suggest you replace ${cmake_args} above (in both plplot and > plplot_lite) by > ${cmake_args} ${PLPLOT_USER_cmake_args} where normally > PLPLOT_USER_cmake_args is not defined, but in your case > you could define it on the cmake command line as > > -DPLPLOT_USER_cmake_args:STRING="-DENABLE_java=OFF;-DENABLE_ada=OFF;-DDEFAULT_NO_CAIRO_DEVICES:BOOL=ON" > > (Note how the list of cmake options masquerades as a semicolon-separated series of > cmake options). > > In other words, a minor change to plplot/CMakeLists.txt and > plplot_lite/CMakeLists.txt plus invoking cmake for epa_build with the > above option should implement your feature request. Sounds like a good idea. I'll try it. > > > > I then tried the cmake based tests in the install tree. > > > > make test_noninteractive failed becauase the epa built itcl / itk > > libraries were not found. There is no rpath information for these, > > even though the other libraries are fine. Setting LD_LIBRARY_PATH > > allowed me to continue and then the examples ran fine. > > The PLplot build system does specifically set and use RPATH variables > for the Tcl and Tk libraries. If those are empty, that is because > somehow they have been set to system locations which are filtered out > to nothing by design (since you never want rpath to point to system > locations) rather than the desired epa_build buildtools location. I > suspect you might not have followed the directions in README with > regard to the epa_build of buildtools and setting up your epa_build > environment by sourcing a version of setup/setup_linux that has been > tailored to your own particular locations for everything. Anyhow, > when I follow those directions here, I get the following RPATH results: > > -- TCL_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib > -- TCL_TK_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib > -- TCL_TK_ITCL_ITK_RPATH = /home/wine/newstart/build_script/install-linux_buildtools/lib;/home/wine/newstart/build_script/install-linux_buildtools/lib/itcl3.4;/home/wine/newstart/build_script/install-linux_buildtools/lib/itk3.3 > > If you don't get lines similar to the above, then those variables have > been emptied because they point to the system locations as explained > above. The above variables are used appropriately in the PLplot build > system so at least for my case is not necessary for me to set > LD_LIBRARY_PATH. I get just this, so cmake is setting the RPATH variables correctly. ldd on libplplotd.so in the build directory looks fine, but ldd in the install directory can't find itcl or itk. The tcl and tk libraries are found fine in their epa install location. This is most odd... > > > > Tried to run build_plplot which fails straight away with > > > > 1%] Performing download step (verify and extract) for 'build_qt4_lite' > > cd /tmp/build_plplot/build_dir-linux/epa_build/Source && /nfs/see-archive-15_a58/l > > ecanr/software/plplot/build_script/install-linux_buildtools/bin/cmake -P /tmp/buil > > d_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/verify-build_qt4_lite.cmak > > e > > -- verifying file... > > file='/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz' > > CMake Error at /tmp/build_plplot/build_dir-linux/epa_build/Stamp/build_qt4_lite/ve > > rify-build_qt4_lite.cmake:5 (file): > > file MD5 failed to read file > > "/home/software/build_qt4/qt-everywhere-opensource-src-4.8.5.tar.gz": No > > such file or directory > > > > Looks like this points to a file on Alan's hard disk rather than trying > > to download. You probably want to comment out the temporary debugging line > > before the release. I'll commit that change myself now. > > Having done that the > > build is now chugging away. More later... > > Thanks for spotting and fixing that issue and also giving epa_build a try on CentOS > 5.10. More later in response to your finished epa_build results. Andrew |