From: Alan W. I. <ir...@be...> - 2017-08-03 18:56:12
|
On 2017-08-02 19:36-0000 Arjen Markus wrote: >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> 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 __________________________ |