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/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/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/Windows:/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
__________________________
------------------------------------------------------------------------------
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
