-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defect: OpenCoarrays-2.1.0, ISO_Fortran_binding_tests.c:53:10: error: conflicting types for '_errno' #550
Comments
@jbmaggard Thanks for the thorough report! Could you submit a pull request with the mentioned workaround (changing |
Any change you can copy the output here? Also, can you remind me what, if anything, you had to do to compile with msys? I remember some MPI shenanigans of some type. (I think CMake provides the infrastructure for generating the interface .lib files or whatever they're called.) Right now, I only have access to the Intel MPI runtime on windows, so I'm not sure if I can compile code with CMake to link against it; Intel compiler/composer xe products on Windows confuse me. |
@zbeekman your commit LGTM, thanks. As a total git beginner, my understanding is that I would:
Feedback appreciated. |
@jbmaggard I meant not how would you go about creating a PR, as I'm going to do that for you on this issue (at least to replace the instances of
What I'm wondering is separate from the questions you've answered:
Also, I just looked through your output, and I have no idea why iso_fortran_binding is segfaulting, and I'm guessing that the failed images tests are failing due to lack of intel MPI support. I'd like to try to figure out why the tests are failing, but unless you run Thanks! |
Fix for ctest 74 of OpenCoarrays-2.1.0, test-installation-scripts.sh.
Similar to the way on the other add_test() lines, where the cafrun bash script has to be executed under the bash shell, rather than executed as a Win64 executable.
On gendef and dlltool, see bullet three on this comment on #541. Note that gcc would link correctly if impi.dll were supplied on the command line, but due to the way the mpifort and mpicc scripts (from MPICH-3.2) are written, I thought it was cleaner to create libmpi.a, as an import library to impi.dll.
|
Here is a file with the output from from "ctest --ouput-on-failure" (with test 74 fixed as discussed above). The output on test 75 matches what I get executing from MSYS2 bash command line with cafrun, and what I get from manual execution under Intel's mpiexec.exe from Win7-64 Command Prompt. ctest also gave this output. I still haven't determined what changed from my successful run of test 75, ISO_Fortran_binding_tests in the first post of this issue. On one attempt, I got an an error message talking about virtual memory or swapfile, which would seem to agree with some type of allocation problem(s).
On the failed image tests, I'd like to investigate whether GCC and Intel-MPI have the required elements. However, I have not yet been able to find simple, short test programs to try each part. The following list of elements are found in mpi.h when running install.sh, and turn on -DUSE_FAILED_IMAGES (see NEEDED_SYMBOLS in OpenCoarrays-2.1.0/src/mpi/CMakeLists.txt)
|
Fix #550: conflicting types for `_errno`
uname -a
: MINGW64_NT-6.1 PE-MGR-LAPTOP 2.10.0(0.325/5/3) 2018-02-09 15:25 x86_64 MsysAttempted to build native Win64 CAF, using GCC 7.3.0 and OpenCoarrays-2.1.0 under MSYS2, following the procedure described in #541. No surprises until compiling OpenCoarrays-2.1.0/src/tests/unit/iso-fortran-binding/ISO_Fortran_binding_tests.c.
Full output from install.sh and output from make clean; make VERBOSE=1 are posted in web folder, along with a copy of the stddef.h file.
A workaround, replacing all instances of "errno" with "iso_errno" in ISO_Fortran_binding_tests.c, appears to have been successful, passing ctest 75, after a clean install.sh build (having deleted the install and builds folders).
The image_fail tests were not passed as previously discussed for 2.0.0 in #541, and the test-installation-scripts.sh fails (BAD_COMMAND) due to ctest trying to execute it as a Win64 executable file, rather than a bash script (note, installation was successful from install.sh).
The text was updated successfully, but these errors were encountered: