Re: [Plplot-devel] Intermittent Ada example build failures are now gone again!

[Alan W. Irwin]

On 2018-04-15 11:15-0700 Alan W. Irwin wrote:


Hi Jerry:

[...]

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

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.


Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I
was using for Debian Jessie) the first test of Ada has been a complete success.
See commit 994723471 for the details of the tests I ran.

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

Re: [Plplot-devel] Intermittent Ada example build failures are now gone again!

[Alan W. Irwin]

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

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

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] Intermittent Ada example build failures are now gone again!

[Alan W. Irwin]

My last commit message (for commit 0df4e30) contained the following
paragraph concerning intermittent Ada example build failures during
various comprehensive tests that I encountered:

"These checks showed intermittent failures for certain parts
(xtraditional28a, xtraditional33a) of the Ada part of the build with
two separate complaints about various files written by the gnat
compiler.  At this stage I cannot figure out the source of this issue
since it comes and goes and is hard to reproduce.  But at one point I
got through the entire test above without Ada failures, and found an
obvious issue with the static OCaml binding library which I fixed and
which has absolutely nothing to do with Ada.  I then tried the test
above again, which failed for the nondynamic case for the build of one
of the Ada examples.  I then followed up by a specific static build of
the ocaml binding library that exercised the fixed build-system CMake
code for that case, and all was well.  Therefore, I think from these
piecemeal results that all is well with the current commit, but
further testing needs to be done as above once I figure out the source
of the intermittent Ada build errors."

One possibility to explain intermittent failures like this is some
hardware issue.  But after the above result I hammered my box with all
sorts of hardware tests which it passed with flying colours.  Part of
those tests involved a system reboot, and after that the comprehensive
test that previously was failing in different places due to different
Ada example build issues on successive runs completed with perfect
results!  Which is a nice result since it confirms the intrusive
changes I made for commit 0df4e30 are valid.  Furthermore, because the
Ada results were perfect for this comprehensive test after a reboot,
and many prior tests except for the ones used for this particular
commit for a Linux operating system that had been up for a long time,
there is a possibility that the gnatmake issue on Linux is it becomes
unreliable if the Linux platform is up too long.

So those good hardware tests, the good Ada example builds (and all
other builds and tests) that occurred in the comprehensive test
*after* a reboot, and the intermittent failures before the reboot just
for this commit occurring just for Ada example builds argues strongly
these intermittent failures are not due to hardware issues.  So that
leaves some issue with one or all of the components (gnatlink, etc.)
of my system gnatmake Ada build tool or the software stack those
components depend on as the likely culprit for the intermittent Ada
example build failures in this case.  And one possibility is the Linux
kernel itself was beginning to get wonky after many days up, and
gnatmake is peculiarly sensitive to such issues.

Anyhow, if you combine that bad gnatmake experience on Linux with
Arjen's known difficulties with gnatmake on Cygwin and Jerry's known
difficulties with gnatmake on Mac OS X, I get the impression that
gnatmake is pretty unreliable regardless of platform (perhaps through
no fault of its own other than possibly a design that depends on the
underlying operating system working perfectly). Anyhow, the observed
gnatmake unreliability is something to keep in mind going forward for
those of you who run into issues with gnatmake.

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