On 2015-05-18 08:17-0000 Arjen Markus wrote: > Please find the results of the comprehensive test on Cygwin using the latest version. It fails in the static build, using the installed examples, but the other configurations seem fine. So we are making progress. What is going wrong with the installed examples is, however, a mystery to me.
The first error message for the case of the traditional build of the f95 examples when PLplot was statically built was as follows: /cygdrive/d/plplot-svn/comprehensive_test_disposeable/static/install_tree/lib/libplplot.a(qt.cpp.o):qt.cpp:(.text+0x5cc0): undefined reference to std::ios_base::Init::Init()' std refers to symbols in the special library that the C++ compiler normally adds to the linking information (in this case the libstdc++ library that is associated with g++, but the name/location/version of that library might depend on which C++ compiler the user decides to use). Of course, in this case we must link the Fortran examples with a Fortran compiler for the traditional build system for the installed example. Therefore, there is a linking error here because libstdc++ is obviously not automatically linked in by gfortran. There are also similar potential problems for other non-C or C++ examples that are compiled. It took some doing (because on Debian wheezy at least any indirectly linked external shared C++ libraries such as the Qt, libLASi, or wxwidgets libraries would transitively suck in a link to a shared version of libstdc++), but I was able to verify this problem on Debian wheezy when I tested a case of psttf alone where the libLASi library used by that device driver was statically built. The linking model I used for this analysis is stated in the commit message for a09dc18, and I have asked Andrew to review that. But fundamentally what that commit does is to avoid comprehensive testing of PLplot components that satisfy the criteria when the linking model indicates the linking of the examples is problematic, i.e., the case of a traditional build of non-C or C++ examples for statically built libplplot where that library contains C++ code from any of the C++ devices). So regardless of the reliability of the linking model that motivates commit a09dc18, that commit should avoid the above f95 problem (since the ada, d, f95, java, and ocaml examples will not be built or tested for that special case). So when you get a chance, please try a comprehensive test again to see if the above commit allows that test to finally run to completion for the Cygwin platform for the case when the traditional build is included in the test. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
