Hi Jerry: On 2018-04-10 14:15-0700 list_em...@icloud.com wrote:
Thanks for your work on trying to figure this out. I really have no
idea what the problem could be. I’ve never had a problem with gnatmake but you recall a problem from the past that pretty much escapes me by now. I was referring to your attempts to get the test_ada project to work on Mac OS X. I have forgotten the details, but as I recall you never had complete success with that test. But on the other hand, the issue you discovered was consistent and that was also true for the issue that Arjen discovered for Cygwin. Therefore, it is likely the issues you guys discovered on two different platforms don't have anything in common with the issue I am dealing with. [...]
I don’t know if you will find this useful, but on https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html at the end of "4.1. Building with gnatmake" appears this: "Note that for advanced forms of project structure, we recommend
creating a project file as explained in the GNAT_Project_Manager chapter in the GPRbuild User’s Guide, and using the gprbuild tool which supports building with project files and works similarly to gnatmake.” [...] Thanks for pointing out the gprbuild possibility. From my further reading in <https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/building_with_gprbuild.html> it appears gprbuild is designed to handle more project complexity than gnatmake, but it is not of sufficient generality to implement complete build systems like is possible with CMake. Furthermore, it appears that gprbuild does not use gnatmake but provides the same functionality at the build level, i.e., it uses the same building blocks (gcc to compile, gnatbind to bind, and gnatlink to link) that gnatmake does. Note it is the gnatlink step where the intermittent errors occur for me. So it is useful to know about the gprbuild possibility, but since CMake has everything covered at the build system level (i.e., does not need to use gprbuild) and gnatmake has everything covered at the detailed (gcc, gnatbind, and gnatlink) building block level I plan to stick with that combination. Here is some recent news about these intermittent Ada build errors. They disappeared for me for several comprehensive tests after a reboot 3 days ago, but yesterday they came back again! That is, I built the test_diff_psc target by hand from scratch and it failed due to Ada. Then I repeated the exact test again, and it succeeded with perfect (PostScript) results and no Ada build issues at all! So rebooting the system may have nothing to do with these errors. Of course, the possibility always exists that intermittent results are due to hardware issues, and the gnat building process may be particularly sensitive to such hardware issues. So after the first encounter with these intermittent Ada build failures, I did some detailed comparisions of rsync results using the --checksum option (which checked that 4 trillion bits on two rsynced disks were the same), RAM tests, disk filesystem checks, and git filesystem checks to see if any hardware issue shows up via such detailed checks, but none did. So those results pretty much restored my confidence that my hardware was fine. So once this Ada build issue appeared again for me yesterday after all those previous successful hardware checks, I did a google search for the terms (without the quotes) "gnatmake intermittent build error" and found <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451> which was a bug report in 2015 about intermittent Ada build issues which was immediately fixed back then. However, my gnat version (= 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure at this stage that bug 65451 is the issue that is causing the intermittent Ada build issues for me. Therefore, I plan to use the -DENABLE_ada=OFF option for my further testing until I can get access to a later version of the Ada build tools myself, and I suggest others who currently don't have access to Ada build tools with bug 65451 fixed should do the same. 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
