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: Here is my promised detailed response to your recent noninteractive comprehensive test report for MinGW-w64/MSYS2.
II. The noninteractive comprehensive test for MinGW-w64/MSYS2
[...] One slightly problematic issue I noted for this platform was you put /d/cmake3.4.3/bin first on your PATH. It appears that your script invocation used --cmake_command "/mingw64/bin/cmake" and your resulting CMakeCache.txt files found that same correct version, but nevertheless, to remove this source of uncertainty I would highly recommend removing this path (/d/cmake3.4.3/bin) to an incorrect (and severely dated) version of CMake from the PATH in your launch script for this platform.
* ERROR: Traditional make test_noninteractive failed in the installed examples tree (for the nondynamic case) A google search for the term <"gcc.exe: Bad address"> didn't appear to find anything relevant. (There was one issue in Cygwin for 2012 involving commands separated with a semicolon, but we don't use a semicolon in the present case.)I tried the following:
- Run the build command explicitly (it is 1800+ characters long!) -
this succeeded without any complaint and the resulting program did its job.
- Run make so that the program would be built. That failed with the "Bad address" message.
My current conclusion is that the length of the command is causing a
problem in make. It may just go over some internal edge. There is not
much PLplot-ish about this, except for the length of the directory
names, it would seem.
Thanks for that extremely useful extra bit of research. So it appears
bash is not complaining about those 1800+ characters, but
make is.
Here is some more research on the issue:
irwin@raven> grep x00c.exe
nondynamic/noninteractive/output_tree/traditional_make_noninteractive.out | grep
-v 'Error 126' | wc
1 78 1882
irwin@raven> grep x00c.exe
shared/noninteractive/output_tree/traditional_make_noninteractive.out | wc
1 32 682
That last grep stanza on that first command was to eliminate the error
message from the count.
So indeed, the non-working nondynamic case has a much longer command
line (than the working shared case (because in the nondynamic case, the
driver object code is in the shared library so _all_ driver library
dependencies have to be mentioned (for the default **transitive** linking
that occurs for the MinGW-w64/MSYS2 platform).
So for this case as well, you might want to try -DNON_TRANSITIVE=ON.
That might work around this issue (there will be a much shorter
command line, if the command-line length really is the issue here),
but I have no clue whether non-transitive linking is as well-supported
by the GNU build tools on MinGW-w64/MSYS2 (and Cygwin for that matter)
as it is on Linux so I wait for your reports concerning
-DNON_TRANSITIVE=ON for both the MinGW-w64/MSYS2 and Cygwin
platforms with a great deal of interest.
Meanwhile, assuming the fundamental issue is command-line length,
I just checked, and all Makefile*.in files in our source tree
contain the following line:
SHELL = @SH_EXECUTABLE@
and for your MinGW-w64/MSYS2 case
# Check for all POSIX tool commands that have been found from the MSYS2 side
irwin@raven> find . -name CMakeCache.txt |xargs grep 'usr/bin'
./shared/noninteractive/build_tree/CMakeCache.txt:CMAKE_MAKE_PROGRAM:FILEPATH=D:/mingw64/usr/bin/make.exe
./shared/noninteractive/build_tree/CMakeCache.txt:ENV_FOR_ONSGMLS:FILEPATH=D:/mingw64/usr/bin/env.exe
./shared/noninteractive/build_tree/CMakeCache.txt:SED_EXECUTABLE:FILEPATH=D:/mingw64/usr/bin/sed.exe
./shared/noninteractive/build_tree/CMakeCache.txt:SH_EXECUTABLE:FILEPATH=D:/mingw64/usr/bin/bash.exe
./shared/noninteractive/build_tree/CMakeCache.txt:TAIL_EXECUTABLE:FILEPATH=D:/mingw64/usr/bin/tail.exe
./shared/noninteractive/install_build_tree/CMakeCache.txt:CMAKE_MAKE_PROGRAM:FILEPATH=D:/mingw64/usr/bin/make.exe
./nondynamic/noninteractive/build_tree/CMakeCache.txt:CMAKE_MAKE_PROGRAM:FILEPATH=D:/mingw64/usr/bin/make.exe
./nondynamic/noninteractive/build_tree/CMakeCache.txt:ENV_FOR_ONSGMLS:FILEPATH=D:/mingw64/usr/bin/env.exe
./nondynamic/noninteractive/build_tree/CMakeCache.txt:SED_EXECUTABLE:FILEPATH=D:/mingw64/usr/bin/sed.exe
./nondynamic/noninteractive/build_tree/CMakeCache.txt:SH_EXECUTABLE:FILEPATH=D:/mingw64/usr/bin/bash.exe
./nondynamic/noninteractive/build_tree/CMakeCache.txt:TAIL_EXECUTABLE:FILEPATH=D:/mingw64/usr/bin/tail.exe
./nondynamic/noninteractive/install_build_tree/CMakeCache.txt:CMAKE_MAKE_PROGRAM:FILEPATH=D:/mingw64/usr/bin/make.exe
So all should be well there, i.e., CMake has found the POSIX version
of the make command rather than the incorrect "mingw" native windows
version of the make command which presumably would have serious
command-line length issues if used for a traditional build (i.e., not
a cmake-based build where all sorts of measures are typically deployed
by CMake to beat Windows command-line limitations for both the POSIX
make case and the native Windows make case).
But I did notice that one possible issue is you simply used "make" for your
comprehensive test.
What does "which make" give you for that platform? Does it refer to
that above D:/mingw64/usr/bin/make.exe POSIX version or something else?
(To avoid this question in future, your invocation scripts for all
platforms should specify the exact make command that is being
used.), e.g.,
--build_command D:/mingw64/usr/bin/make.exe
for MinGW-w64/MSYS2.
But assuming that is not the issue, my working hypothesis is this
command-line length limitation is a MinGW-w64/MSYS2 bug since it does
not appear to be an issue for Cygwin's version of the POSIX make
command.
To investigate that hypothesis further, please
take a look at the extremely simple attached Makefile test case I have created.
On Linux the result (from the otherwise empty directory where this Makefile
is created) is
software@raven> make |wc
1 1 2001
i.e., there is one line with no blanks so there is also one
blank-delimited word generated by that "echo" command inside that
Makefile, and that one line (and word) consists of 2001 bytes.
What happens if you run that test with SHELL suitably modified to the
Cygwin location for bash.exe from the same Cygwin environment you use
to test PLplot?
What happens if you run that test with SHELL changed to
D:/mingw64/usr/bin/bash.exe, see above from the same MinGW-w64/MSYS2
environment you use to test PLplot?
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.
For example, you would need to double-check you could execute that
"echo" command in the Makefile without issues from bash.exe, and that
version of bash.exe was identical to what is specified for the SHELL
variable in the
10 relevant install-tree locations, i.e.,
irwin@raven> grep 'Makefile$' comprehensive_test_listing.out |grep install_tree
-rw-r--r-- 1 markus DIRECTORY+Group(513) 3432 Jul 30 12:09
./nondynamic/noninteractive/install_tree/share/plplot5.12.0/examples/c/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 4145 Jul 30 12:09
./nondynamic/noninteractive/install_tree/share/plplot5.12.0/examples/c++/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 2952 Jul 30 12:09
./nondynamic/noninteractive/install_tree/share/plplot5.12.0/examples/fortran/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 8742 Jul 30 12:09
./nondynamic/noninteractive/install_tree/share/plplot5.12.0/examples/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 2615 Jul 30 12:09
./nondynamic/noninteractive/install_tree/share/plplot5.12.0/examples/tk/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 3411 Jul 30 11:08
./shared/noninteractive/install_tree/share/plplot5.12.0/examples/c/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 4124 Jul 30 11:08
./shared/noninteractive/install_tree/share/plplot5.12.0/examples/c++/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 2927 Jul 30 11:08
./shared/noninteractive/install_tree/share/plplot5.12.0/examples/fortran/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 8738 Jul 30 11:08
./shared/noninteractive/install_tree/share/plplot5.12.0/examples/Makefile
-rw-r--r-- 1 markus DIRECTORY+Group(513) 2577 Jul 30 11:08
./shared/noninteractive/install_tree/share/plplot5.12.0/examples/tk/Makefile
So I have described three possible debugging trails to follow with the
attached simple test case, but my bet is you will find 1. to be true
which should be easy to deal with (e.g., with a bug report to the
MinGW-w64/MSYS2 which I can advise you about) assuming we have also
figured out a PLplot workaround such as -DNON_TRANSITIVE=ON for that
MinGW-w64/MSYS2 bug
Good luck, and I look forward to your next report for the
noninteractive MinGW-w64/MSYS2 case as well as the results of
the above simple tests for the attached Makefile
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
__________________________
Makefile.gz
Description: Compressed simple Makefile to test potential line length issues
------------------------------------------------------------------------------ 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
