@Andrew: I have CC'd you because you are the maintainer for the liblasi-dev Debian (and indirectly Ubuntu) package, and this e-mail provides some background (scan below to the error involving freetype) for a bug report I just made for that package at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845497>. Also, note comments below about an even worse issue for this package (it is based on old buggy version where Hazen ran afoul of one of those bugs).
Hi Hazen: I was glad to see most of my suggestions improved test completeness right away. I will respond below to the ones where there is still a problem, but when you reply please post the exact URL of the relevant report that failed (or succeeded) because they are tough to find amongst all the many different build reports you are generating. On 2016-11-23 12:23-0500 Hazen Babcock wrote: > On 11/23/2016 06:08 AM, Alan W. Irwin wrote: > >> * -- WARNING: CMAKE_VERSION = 3.2.2 is in the range from 3.2 through >> 3.3.1 which has a compromised find ability that was fixed in 3.3.2. >> Please upgrade to 3.3.2 or greater. > > I changed the builds to download and install cmake-3.7.0, which seems to be > working. Excellent news. Just out of curiosity, is cmake-3.7.0 actually provided as an official package by travis-ci, is this the Linux binary version supplied by Kitware, or do you build cmake-3.7.0 for each test? >> * -- Looking for itcl.h - not found >> -- WARNING: Disabling Itcl interface code > > This is still failing with cmake-3.7.0 and the itcl3 and itcl3-dev packages. That sounds like a Tcl find issue. Short story, please try the cmake option -DTCL_INCLUDE_PATH:PATH=/usr/include/tcl8.5 to see if that solves the issue. The (somewhat) longer story is as follows: To analyze this situation further, if you look at <http://packages.ubuntu.com/trusty/amd64/tcl-dev/filelist>, tcl.h should be found at /usr/include/tcl8.5/tcl.h, and if you look at <http://packages.ubuntu.com/trusty/amd64/itcl3-dev/filelist>, itcl.h should be found at /usr/include/tcl8.5/itcl.h Yet your report says the tcl.h location (${TCL_INCLUDE_PATH}) is /usr/include/tcl! That would be OK if that was the result of some Ubuntu consistent symlink /usr/include/tcl -> /usr/include/tcl8.5 since then itcl.h would still be found consistently in that same symlinked directory. But since itcl.h is not found, I assume the trouble is due to some Ubuntu trusty symlink for tcl.h that is inconsistent with the itcl.h location. Thus, to achieve the required consistency, I suggest you try setting TCL_INCLUDE_PATH as above. >> Your detailed install messages for itcl3-dev seemed to successful >> as noted above, but they did include the following warning message >> about 110 packages that needed updating. >> >> 0 upgraded, 2 newly installed, 0 to remove and 110 not upgraded. >> >> To reduce that "not upgraded" number to 0, do the following: >> >> sudo apt-get update >> sudo apt-get dist-upgrade > > I suspect that you can't do that, but I have not actually tried. It is definitely worthwhile on the Debian platform(or Debian derivative platforms such as Ubuntu) to always do that standard upgrade to get access to the latest bug fixes and security fixes. Therefore, I do suggest you do give it a try, and if it works always use it from then on in your tests. > >> On Debian Jessie, the package you need to install is called liblasi-dev. > > This causes the build to fail with: > > Scanning dependencies of target psttf > [ 20%] Building CXX object drivers/CMakeFiles/psttf.dir/psttf.cc.o > In file included from > /home/travis/build/HazenBabcock/PLplot/drivers/psttf.cc:44:0: > /usr/include/LASi.h:14:30: fatal error: freetype/ftglyph.h: No such file or > directory > compilation terminated. > make[2]: *** [drivers/CMakeFiles/psttf.dir/psttf.cc.o] Error 1 > make[1]: *** [drivers/CMakeFiles/psttf.dir/all] Error 2 > make: *** [all] Error 2 > > So I think we are still missing something, a freetype package perhaps? @Andrew: One aspect of the problem is a packaging bug for liblasi-dev which I have documented at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845497>. Also, I have looked at the Release notes for lasi-1.1.2, and the fundamental motivation for that release was to solve issues like the above. So I am pretty sure you put packaging lasi-1.1.2 on your ToDo list at the time of that release, but never got around to it because the Debian package is still for an outdated version, lasi-1.1.0. Should I make an official bug report about this or is this reminder enough? @Hazen: Solution of the above two liblasi-dev packaging bugs will likely solve this issue, but especially until that second issue (old upstream version) is fixed there is not much you can do so I suggest setting -DPLD_psttf=OFF (with a comment about why because you will want to review this once the above package fixes are made and the results are propagated to travis-ci). Also, I just noticed there continues to be a freetype issue that is independent of -dev psttf (or -dev psttfc). When you look at this again, please give me the URL of the relevant report, but from the old report I have been analyzing had the following result for freetype: -- Found Freetype: /usr/lib/x86_64-linux-gnu/libfreetype.so (found version "2.5.2") -- FREETYPE_CFLAGS = -I/usr/include/freetype2 -- FREETYPE_LIBRARIES = /usr/lib/x86_64-linux-gnu/libfreetype.so Fonts not found - disabling freetype I suspect you have to install some truetype fonts to solve this issue. There is a lot of choice available, but one TTF package I install is fonts-freefont-ttf which contains a very large range of TrueType glyphs, and it appears that that package is also provided by Ubuntu trusty. > >> On Debian Jessie, the package you need to install is called >> libwxgtk3.0-dev. > > This causes the build to fail with: > [ 14%] Building CXX object > bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o > In file included from /usr/include/c++/5/type_traits:35:0, > from /usr/include/wx-3.0/wx/strvararg.h:25, > from /usr/include/wx-3.0/wx/string.h:46, > from /usr/include/wx-3.0/wx/memory.h:15, > from /usr/include/wx-3.0/wx/object.h:19, > from /usr/include/wx-3.0/wx/wx.h:15, > from > /home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22: > /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file > requires compiler and library support for the ISO C++ 2011 standard. This > support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. > #error This file requires compiler and library support \ > ^ > In file included from /usr/include/wx-3.0/wx/string.h:46:0, > from /usr/include/wx-3.0/wx/memory.h:15, > from /usr/include/wx-3.0/wx/object.h:19, > from /usr/include/wx-3.0/wx/wx.h:15, > from > /home/travis/build/HazenBabcock/PLplot/bindings/wxwidgets/wxPLplotstream.cpp:22: > /usr/include/wx-3.0/wx/strvararg.h:345:18: error: ‘is_enum’ in namespace > ‘std’ does not name a template type > typedef std::is_enum<T> is_enum; > ^ > /usr/include/wx-3.0/wx/strvararg.h:349:54: error: ‘is_enum’ was not declared > in this scope > enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value > }; > ^ > /usr/include/wx-3.0/wx/strvararg.h:349:68: error: template argument 1 is > invalid > enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value > }; > ^ > make[2]: *** > [bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/wxPLplotstream.cpp.o] > Error 1 > make[1]: *** [bindings/wxwidgets/CMakeFiles/plplotwxwidgets.dir/all] Error 2 > make: *** [all] Error 2 > > Not sure how to set compiler flags, I will have to investigate further. Or > maybe cmake should be doing this for us? Try setting the environment variable CXXFLAGS as a workaround. But I don't need to do that here so I suspect the problem is a fundamental mismatch between the old wxwidgets system libraries available to you on Ubuntu trusty and the (much newer) g++ compiler versions that are available to you with travis-ci. So I suspect that workaround won't help much, and you will have to set -DPLD_wxwidgets=OFF (or drop installing the wxwidgets development libraries) until travis-ci makes a newer set of Linux libraries available. >> * make[2]: Circular examples/python/x00 <- examples/python/x00 >> dependency dropped. >> >> And many, many more such messages. > > Using cmake-3.7.0 seems to have fixed this. Excellent. I was quite concerned by that issue, but that good result with cmake-3.7.0 confirms my prejudices against early versions of CMake such as 3.1.x through 3.4.x. The CMake developers actually didn't introduce too many changes for 3.0.2 compared to 2.8.x so that remains a reasonably reliable version outside of one known permission issue I had to work around in the PLplot build system. But there was a flood of CMake changes for 3.1.x onwards so it took many subsequent versions to wring out all the bugs that were introduced by those changes. >> Note, if travis-ci somehow precludes you from switching Ubuntu from >> trusty to Ubuntu yakkety (admittedly a pretty drastic change) in >> either of the two ways above, then that would force you to build >> cmake-3.7.0 as part of each of your tests, and that would obviously be >> slower than the above change to yakkety (if allowed by travis-ci). > > I used the cmake-3.7.0 binary so that I don't have to compile it. It would be > nice if they provided more recent distros but I'm not holding my breath.. Well, my opinion is CMake-3.7.0 + trusty is marginal rather than a disastrous combination. So travis-ci will eventually have to move to something newer, and it is beginning to get urgent. So "eventually" may come soon since they have supported precise and trusty (released in April of 2012 and 2014) which are both LTS (long-term-support) Ubuntu distributions. The next LTS Ubuntu distribution was xenial (16.04LTS) which from the numerical code was released in April this year. So it is disappointing that travis-ci has not yet moved to xenial in the 7 months since that release, but perhaps that will happen "real soon now"? By the way, I also view my own platform, Debian stable = Jessie (released in April 2015 so a year newer than trusty) as marginal (i.e., on the edge of being too old). So sometime in the next few months I plan to switch to Debian stretch (the "testing" rolling release). Note stretch is in a freeze state now or soon will be in preliminary preparation for releasing it as the next Debian stable release some time in 2017. So Debian stretch should already be a pretty reliable testing platform for PLplot. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
