Hi Alan,
Thanks for this analysis and the suggested steps for further investigation of
this puzzle. I hope to have time this weekend to investigate this.
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Thursday, August 03, 2017 8:56 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: RE: [Plplot-devel] Planning for the release of 5.13.0
>
> On 2017-08-02 19:36-0000 Arjen Markus wrote:
>
> >> -----Original Message-----
> >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> >> Sent: Tuesday, August 01, 2017 9:57 AM
> >>
> > ...
> >> 1. If you get good results in the Cygwin case, but not the
> >> MinGW-w64/MSYS2 case, then that is pretty good evidence of a bug in
> >> the
> >> MinGW-w64/MSYS2 "make" package.
> >>
> >> 2. If both don't work, then that means long command lines work in
> >> neither, and perhaps we have to write off this PLplot issue for the
> >> MinGW-w64/MSYS2 case to longer path names/longer command lines in
> >> that case compared to the Cygwin case. But I consider this result to
> >> be unlikely because according to
> >> <https://stackoverflow.com/questions/19354870/bash-command-line-
> >> and-input-limit>
> >> the Cygwin bash line limit is 32000 bytes, i.e., well above the 2001
> >> bytes generated above.
> >>
> >> 3. But if both work, then you will have to dig deeper.
> >>
> >>
> > There is but a single bash.exe on the system and the makefile you sent works
> perfectly on both Cygwin and MinGW.
>
> Hi Arjen:
>
> Actually, you must have at least two different bash.exe executables installed
> on
> your computer, one from Cygwin and one from MinGW-w64/MSYS2. So I think you
> meant the following, but just to be absolutely clear, can you double check
> that only
> the Cygwin-installed version version of bash.exe was on your PATH for the
> Cygwin
> experiment and only the MinGW-w64/MSYS2-installed version of bash.exe was on
> your PATH for the MinGW-w64/MSYS2 experiment? Each are likely installed in
> the
> "/usr/bin/bash.exe" location on both platforms, but those are two very
> different
> places so, e.g., "ls -l /usr/bin/bash.exe" will show different dates and
> lengths for
> those two different files when run from Cygwin and MinGW-w64/MSYS2. Of
> course, the best thing to do in each case for your tests is to run bash.exe
> using its
> full path name starting with a drive letter which is unambigous. And as I
> said before,
> you should be doing the same for make.exe (and cmake.exe and
> ctest.exe) when your invocation script runs the comprehensive test script.
>
> > Your example did inspire me to try "gcc -o x x.c
> -DLONG=01234.....89" instead of "echo".
>
> > That, however, works perfectly
> as well. There must be something much more specific that is causing this. For
> the
> moment I have run out of easy-to-test ideas though.
>
> Such experiments as the one you tried above (and the further one you tried in
> a
> later post) are extremely useful.
>
> So assuming you really are using two different versions of bash for this
> test, then
> you have confirmed there are no line-length issues for make for either Cygwin
> or
> MinGW-w64/MSYS2 which is a big step forward.
>
> Stepping back a bit from these details, it seems to me the fundamental issue
> here
> is you have a comprehensive test failure that you have not yet been able to
> reproduce by hand. So let's go back and see exactly why you cannot (so far)
> replicate by hand. Furthermore, to take advantage of the results accumulated
> on
> disk by your last comprehensive test with -DNON_TRANSITIVE=ON, let's stick
> with those.
> (Those results were identical to your previous ones without that option other
> than
> linking commands were much shorter.)
>
> The key here is to attempt to reproduce the bad script result by following
> all the
> essential steps that script does. For example, from the report you sent of
> the -
> DNON_TRANSITIVE=ON case just prior to the error there was this messaged
> emitted by the script:
>
> 'Prepend "/d/plplot-
> svn/comprehensive_test_disposeable/nondynamic/noninteractive/install_tree/bin"
> to
> the original PATH
>
> That's really important since it sets the exact (nondynamic) versions of the
> PLplot
> libraries that are being used for this part of the test you are trying to
> replicate.
>
> That original PATH (according to that report) is
>
> PATH="/d/cmake3.4.3/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/Syst
> em32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPo
> werShell/v1.0/"
>
> So for this attempt at hand replication, do make sure to set PATH as
> follows:
>
> export \
> PATH="/d/plplot-
> svn/comprehensive_test_disposeable/nondynamic/noninteractive/install_tree/bin:/d/
> cmake3.4.3/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Wi
> ndows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1
> .0/"
>
> Also, (again following the report) you should set the environment variable
>
> export \
> PKG_CONFIG_PATH="/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig"
>
> Then (still following what the script does)
>
> cd \
> /d/plplot-
> svn/comprehensive_test_disposeable/nondynamic/noninteractive/install_tree/share/
> plplot5.12.0/examples/c
>
> make x00c.exe
>
> Does that make command (or much better yet its fullpath equivalent that
> starts with
> a drive letter) replicate the "Bad address" error?
>
> If not, then it appears the most likely explanation is I have forgotten
> something
> essential that the script does, and I will have to dig deeper.
>
> But assuming (now that both PATH and PKG_CONFIG_PATH are set properly and
> you are using an unambiguous make command of the correct form for
> MinGW-w64/MSYS2) you can replicate by hand this way, can you replicate in even
> a simpler way by running the exact same gcc command that the make command
> does?
>
> 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
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
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
