[Plplot-devel] Planning for the release of 5.13.0 --Cygwin Ada issue

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

On 2017-07-31 07:13-0000 Arjen Markus wrote:

> Here are some results from my most recent, i.e. yesterday's, testing session.

Hi Arjen:

I first want to emphasize that I am well aware I am asking for a lot
of testing from you, and thanks in advance for anything you can do!

Of course, the concern here is 40 per cent of our downloaders (as
measured by SourceForge from the 5.12.0 release date until today) use
some form of Windows, and ideally you and other here with access to
Windows platforms would comprehensively test on MinGW-w64/MSYS2, MSVC,
and Cygwin to reduce the number of bugs that our Windows users find
post-release, and also to identify the limitations (which components
have to be dropped) on each of those platforms.

Of course, this is all in the ideal case, and if testing from you over
the next few weeks is going to be severely constrained by other calls
on your time, then please do as much as you can **but also
communicate your time constraints to me**.  Then depending on what you
say, the progress I am making on some remaining irritating Linux
issues (how superscripts/subscripts and linebreak "\n" commands are
handled for wxwidgets and other devices), and in the interest of
getting out our fixes and new features in a timely manner, I will
likely decide to go ahead and release PLplot-5.13.0 without as much
Windows testing as we would like. (And likely not as much
superscripts/subscripts and linebreak fixing as I would like.)

More below in response to your Ada Cygwin report.  I will wait until
later to respond to your other two reports (with appropriatly modified
subject lines) to keep the size of each e-mail reasonable.

>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Wednesday, July 19, 2017 1:43 AM
>> To: Arjen Markus
>> Cc: PLplot development list
>> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>>
>> I. The noninteractive comprehensive test for Cygwin.
>>
>> * Find issues
>>
>> My records indicate you last ran a comprehensive test for Cygwin on 2016-12-15.
>> The options for that test were the same as the present ones, and that script was a
>> complete success.
>
> ...
>
>>
>> So the changes from December are the wxwidgets device driver is not present and
>> there is also a severe regression in enabled bindings.
>>
>> Is this exactly the same Cygwin system and launch script that you used before
>> when testing just before the release of PLplot-5.12.0?  If so, you should be able to
>> replicate those good December results by switching to PLplot-5.12.0 (e.g., by
>> running
>>

> It appears that when you add a package to the Cygwin installation,
an update follows for all the packages that are already present. This
led to me having to adjust the location where the Ada stuff is to be
found (change in version). I also had to add a few Python packages
(transition from Python 2 to Python 3).

That sounds like good package management on Cygwin's part to make sure
your system remains self-consistent.  (In contrast you have recently
run into inconsistent system problems for MinGW-w64/MSYS2, and those
are no fun at all.)

> Unfortunately, the new Ada packages result in a problem with
multiply defined symbols - see the corresponding tarball. So I had to
remove that from the test (by not expanding/explicitly setting the
CMAKE_LIBRARY_PATH environment variable).

It turns out this is a long-standing issue, see your post from
more than a year ago

2016-03-17 Arjen Markus    (21K) RE: comprehensive testing results on Cygwin - Ada build errors

However, I think I have a lot better understanding of the issue now,
then I did back then.

The command that leads to the build failure is

/usr/bin/gnatmake.exe  -Wl,--enable-auto-import "-aI/cygdrive/d/plplot-svn/plplot-git/examples/ada" "-aI/cygdrive/d/plplot-svn/plplot-git/bindings/ada" "-aL/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/noninteractive/build_tree/bindings/ada/CMakeFiles/plplotada.dir" xtraditional13a.adb -cargs  -largs ../../dll/libplplotada.dll.a ../../dll/libplplot.dll.a /usr/lib/libltdl.dll.a /usr/lib/libdl.a /usr/lib/libshp.a /usr/lib/libfreetype.dll.a ../../dll/libcsirocsa.dll.a ../../dll/libcsironn.dll.a /usr/lib/libqhull.dll.a ../../dll/libqsastime.dll.a

The equivalent command (which works without issues) on my Debian Jessie platform is

/usr/bin/gnatmake  "-aI/home/software/plplot/HEAD/plplot.git/examples/ada" "-aI/home/software/plplot/HEAD/plplot.git/bindings/ada" "-aL/home/software/plplot/HEAD/build_dir/bindings/ada/CMakeFiles/plplotada.dir" xtraditional13a.adb -cargs  -largs ../../bindings/ada/libplplotada.so.2.1.0 ../../src/libplplot.so.14.0.0 -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/ada:/home/software/plplot/HEAD/build_dir/src

The Cygwin version of that command seems right to me for that platform
except for possibly one issue which is the huge overlinking that
occurs for that case, e.g., all the libraries mentioned by the -cargs
-largs option.  For Cygwin those libraries are both direct
(libplplotada, and libplplot) in our build tree) dependencies of the
Ada example build and also indirect (libcsirocsa, libcsironn, and
libqsastime.dll that PLplot builds for itself, and the system
libraries libltdl, libdl, libshp, libfreetype, and libqhull)
dependencies of the Ada example build (i.e., direct and indirect
dependencies of libplplot but not direct dependencies of the Ada
example build).  The (working) Linux version of the above command
points to just the direct dependencies of the Ada example build.  In
other words, (by default, see cmake/modules/plplot.cmake) our build
system by design uses non-transitive linking (i.e., only direct
dependencies) for POSIX platforms such as Linux, but transitive
linking (where every library is linked in that is mentioned indirectly
or directly) for non-POSIX platforms such as MinGW-w64/MSYS2, MSVC,
**AND Cygwin**.

But Cygwin prides itself on being mostly POSIX compatible. So I am
beginning to wonder if our default build-system rule is a mistake for
Cygwin that doesn't matter ordinarily, but gnatmake is perhaps
sensitive to this gross overlinking issue?

So to test that possibility, please use the -DNON_TRANSITIVE=ON cmake
option for this test to see if (a) you get further with Ada, and (b)
if that option causes issues for other parts of our comprehensive
tests for the Cygwin platform.  And depending on what combination of (a)
and (b) you obtain, I will take it from there.

Best wishes, and more later concerning your other two reports.

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
__________________________