Re: [Plplot-devel] Possible fix for the test_ada project on Cygwin (NO LONGER RELEVANT)

[Alan W. I. <ir...@be...>]

On 2017-11-08 07:49-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Tuesday, November 07, 2017 11:20 PM
>>
>> Hi Arjen:
>>
>> To clean up some preliminary stuff, please don't set GNAT_LIB unless absolutely
>> necessary.  Specifying that variable is a workaround that bypasses all testing of the
>> find_library command (see
>> <https://cmake.org/cmake/help/v3.10/command/find_library.html> for why that is so.
>
> Oh, that was a stupid mistake - too many little tasks clogging my head and thus I simply followed the advice from the error message: an unaided "comprehensive_test_ada.sh" does not find the Gnat library.
>

> With CMAKE_LIBRARY_PATH set to the right directory the test does
succeed but fails in the same way as before. So the CMake build script
finds the proper library, but there is something going on with the
library itself.

I agree with that general conclusion based on what I see in your report
tarball for this shared case.  But I would add that the fundamental
run time error you are seeing is

raised PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION

for the hello.exe that is built from the installed example source
code.  And for me any error message that mentions "access violation"
in any way likely means there is a memory management issue.  So I
think the most obvious next step is to run a memory management
analysis tool like valgrind (although not that exact tool since it
apparently does not work on Windows platforms) on the hello.exe
executables that are built in the build tree and the install tree.

> I have attached two tarballs: one with only the CMAKE_LIBRARY_PATH
set and one excluding the shared build, leaving the static case. This
fails on account of duplicate symbols again.

I also looked at that additional report tarball, and the build system has done
everything in the static case that I thought it should do, i.e.,
always link with import form of the gnat library regardless of whether
the test_ada Ada library is built as a shared library (which builds
without issues from your other report tarball) or as a static library
(this case which you have just showed obviously does not build correctly).  So
please follow up by using GNAT_LIB in this emergency situation for the
static case to specify libgnat.a, and let me know those results
to help guide me toward the correct find_library configuration
for the normal case where CMAKE_LIBRARY_PATH is specified on Cygwin.

> No time right now to look into your other suggestions.

I promise to be patient.  And in any case I think we are headed toward
preparing a bug report for the Ada components of the gcc toolchain on
Cygwin.  So patience is needed in any case because that bug (once we
isolate it for the simplest case possible and prepare the bug report)
is likely going to take some time for the Cygwin gcc package
maintainers or possibly even the upstream Ada compiler developers to
fix.

Nevertheless, even though I think we are likely stuck in a long
process, I would like to continue moving forward with that process
without too many inefficient long gaps.  So the next chance you have
to work on PLplot I would appreciate it if you followed up with this
issue in the two ways I have suggested above.

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
__________________________