- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have been handed a code to execute on Windows environment, where the same code ran without any problem on LINUX.
Here is an outline of the code execution plan:
- Compile a C code (hapsug.c) to create an object (hapsug.obj) file.
- Compile a Fortran(findhap4_c.f90) code which uses the C object to run.
Command to run a C Code:
C:\Gitlabstuff\FindhapScript1>icl -c hapsug.c Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. hapsug.c
Command to run a Fortran Code:
#Once the above compilation has produced a hapsug.obj then run: ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f90 hapsug.obj -o findhap4 -static -openmp -C -ftrapuv -fpe1 -traceback -warn -reentrancy -D _MYMKL=.TRUE. -L$MKLPATH -verbose #-heap-arrays
Error:
findhap4_c.f90(337): error #8110: The module file for compiler-generated interface was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read. Use -gen-interfaces option. [NHASH__GENMOD]
nn = nhash(0,-1,ids,maxped2,maxn)
^
findhap4_c.f90(337): error #7977: The type of the function reference does not match the type of the function definition. [NHASH]
nn = nhash(0,-1,ids,maxped2,maxn)
^
findhap4_c.f90(337): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
nn = nhash(0,-1,ids,maxped2,maxn)
^
[ Aborting due to internal error. ]
compilation aborted for findhap4_c.f90 (code 1)
Specs:
Compiling all in Intel Parallel Studio XE 2017 > Compiler and Performance Libraries > Command Prompt > IA-32 Visual Studio 2015 environment
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Under Windows, the Intel Fortran compiler convention requires that external routine names be uppercase by default. Therefore, change hapsug_c_ to HAPSUG_C in your C source file.
Similarly, some of the compiler options are named differently in Linux and Windows. For example, /Qopenmp instead of -openmp. Most compilers and linkers expect the -o prefix to be used to name the output object or executable file, so -openmp risks being taken to mean "the output file name is 'penmp'".
You should not expect compatibility between object files built with GCC and object files built with Intel Fortran under Windows.
With the two modifications that I mentioned, and using Intel C instead of GCC, I was able to build and run your program. It seemed to run correctly, ending with the two lines
325 records written to genotypes.imputed Program findhap.f90 completed normally
Details of the compiler options for Linux and Windows are listed in the compiler documentation.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I compile a C code using gcc compiler (http://www.mingw.org/) just to mimic the same LINUX file, it creates an object file (hapsug.o) for me.
Then I compile the fortran code:
C:\Gitlabstuff\FindhapScript1>ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f90 hapsug.o -o findhap4 -static -openmp -C -ftrapuv -fpe1 -traceback -warn -reentrancy -D _MYMKL=.TRUE. -L$MKLPATH -verbose
Error:
-out:findhap4.exe
-debug
-pdb:kinds.pdb
-subsystem:console
-incremental:no
-defaultlib:libiomp5md.lib
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
kinds.obj
findhap4_c.obj
nhash.obj
hapsug.o
findhap4_c.obj : error LNK2019: unresolved external symbol _HAPSUG_C referenced
in function _MAIN__
hapsug.o : error LNK2019: unresolved external symbol _printf referenced in funct
ion _show_matrix_2
findhap4.exe : fatal error LNK1120: 2 unresolved externals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note that as a general rule, the syntax of command line options for the Fortran compiler are different between the Windows and Linux forms of the compiler. Some options do have the same "name", and the windows compiler driver also understands the use of a leading `-` to introduce the option name, so you might get away with this for simple cases, but to avoid potentially confusing problems later your really should be translating each option by referencing the ifort documentation. For example, the Windows option to enable OpenMP is `/Qopenmp`, not `-openmp` (which isn't the documented linux variation of that option either!).
The errors in the opening post suggest that compiler generated module files - with a file extension of *.mod - (in this case, the modules generated by the compiler for interface checking) that were built on the Linux machine were present alongside of the source code on the Windows machine. Get rid of them.
Other errors are likely due to the source code making Linux (and perhaps machine bitness) specific assumptions around the types/kinds of variables and the way the Fortran compiler generates external symbols for the linker. I'll guess that the Fortran code is not using the standard Fortran-C interoperability features of the language. I need to see some code to comment further.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree with IanH.
Also the Abort internal error is not something that should happen regardless of the input files or compiler options used. If it is at all possible to share the .f90 files with us then I can try reproducing the internal error and report that to Development for them to investigate and repair.
I do not know if these converted command-lines will suffice for compiling on Windows but you might try and see.
icl /c hapsug.c
ifort /debug /Od hapsug.obj /exe:findhap4 /static /Qopenmp /check /Qtrapuv /fpe:1 /traceback /warn /reentrancy /D _MYMKL=.TRUE. kinds.f90 findhap4_c.f90 nhash.f90 hapsug.obj
I can't judge the need for MKL nor whether MKL is installed under default paths on your Windows system. Maybe you can get by with simply using the /Qmkl option which is designed to provide some default paths/libs that sometimes suffice. Some uses of MKL require a more custom set of linking options. If you want to try that option, drop it in just after the /reentrancy above.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Under Windows, the Intel Fortran compiler convention requires that external routine names be uppercase by default. Therefore, change hapsug_c_ to HAPSUG_C in your C source file.
Similarly, some of the compiler options are named differently in Linux and Windows. For example, /Qopenmp instead of -openmp. Most compilers and linkers expect the -o prefix to be used to name the output object or executable file, so -openmp risks being taken to mean "the output file name is 'penmp'".
You should not expect compatibility between object files built with GCC and object files built with Intel Fortran under Windows.
With the two modifications that I mentioned, and using Intel C instead of GCC, I was able to build and run your program. It seemed to run correctly, ending with the two lines
325 records written to genotypes.imputed Program findhap.f90 completed normally
Details of the compiler options for Linux and Windows are listed in the compiler documentation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
Under Windows, the Intel Fortran compiler convention requires that external routine names be uppercase by default. Therefore, change hapsug_c_ to HAPSUG_C in your C source file.
Similarly, some of the compiler options are named differently in Linux and Windows. For example, /Qopenmp instead of -openmp. Most compilers and linkers expect the -o prefix to be used to name the output object or executable file, so -openmp risks being taken to mean "the output file name is 'penmp'".
You should not expect compatibility between object files built with GCC and object files built with Intel Fortran under Windows.
With the two modifications that I mentioned, and using Intel C instead of GCC, I was able to build and run your program. It seemed to run correctly, ending with the two lines
325 records written to genotypes.imputed Program findhap.f90 completed normallyDetails of the compiler options for Linux and Windows are listed in the compiler documentation.
Thanks for looking into it. I applied your suggested changes as described below:
Change 1:
void hapsug_c_void HAPSUG_C(int *i, int *maxped, int ped[], ....
Compiled the C script:
C:\Gitlabstuff\FindhapScript1>icl -c hapsug.c Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi on 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. hapsug.c
Object File produced: hapsug.obj
Change 2:
Changed my Fortran compile command to:
ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f90 hapsug.obj -o findhap4 -static /Qopenmp -C -ftrapuv -fpe1 -traceback -warn -reentrancy -D _MYMKL=.TRUE. -L$MKLPATH -verbose #-heap-arrays
Compiled the Fortran script:
C:\Gitlabstuff\FindhapScript1>ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f9 0 hapsug.obj -o findhap4 -static /Qopenmp -C -ftrapuv -fpe1 -traceback -warn -re entrancy -D _MYMKL=.TRUE. -L$MKLPATH -verbose #-heap-arrays Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. ifort: command line warning #10006: ignoring unknown option '/O0' ifort: command line warning #10006: ignoring unknown option '/ftrapuv' findhap4_c.f90(46): remark #7712: This variable has not been used. [K1] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_ size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, to t_count -------------------------------------------------------------------------------- ------------------------------------^ findhap4_c.f90(46): remark #7712: This variable has not been used. [K2] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_ size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, to t_count -------------------------------------------------------------------------------- ----------------------------------------^ findhap4_c.f90(46): remark #7712: This variable has not been used. [INSIDE_COU NTER2] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_ size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, to t_count -------------------------------------------------------------------------------- -------------------------------------------------------------^ findhap4_c.f90(48): remark #7712: This variable has not been used. [PRINT_NOW] logical sug_comp_bool, print_now, show_debug ------------------------^ findhap4_c.f90(48): remark #7712: This variable has not been used. [SHOW_DEBUG ] logical sug_comp_bool, print_now, show_debug -----------------------------------^ findhap4_c.f90(96): remark #7712: This variable has not been used. [MISSING] integer*1 code(0:35), decode(90), missing/5/ ------------------------------------^ findhap4_c.f90(98): remark #7712: This variable has not been used. [DOMAIN_GET _MAX_THREADS] integer :: domain_get_max_threads, get_max_threads -------------^ findhap4_c.f90(98): remark #7712: This variable has not been used. [GET_MAX_TH READS] integer :: domain_get_max_threads, get_max_threads -------------------------------------^ findhap4_c.f90(102): remark #7712: This variable has not been used. [MATCHCODE ] character*2 cthrds, matchcode(7) -----------------------^ findhap4_c.f90(1583): remark #7712: This variable has not been used. [SEG] maxloc, maxhap, nhap, previous, suggest, seg, & ---------------------------------------------^ findhap4_c.f90(1593): remark #7712: This variable has not been used.integer i, j, k, l, ii, new, starti, stopi, hold ------------------^ findhap4_c.f90(1899): remark #7712: This variable has not been used. [MAXCOL] integer start_1, stop_1, start_2, stop_2, i, j, maxcol, col, start_show, end _show ----------------------------------------------------^ ipo: warning #11010: file format not recognized for C:\Gitlabstuff\FindhapScript 1\hapsug.obj ipo: error #11018: Cannot open #-heap-arrays Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib kinds.obj findhap4_c.obj nhash.obj hapsug.obj #-heap-arrays hapsug.obj : fatal error LNK1112: module machine type 'x64' conflicts with targe t machine type 'X86'
Error:
hapsug.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Use the ifort command-line that I provided earlier with the Windows specific options syntax and the source change mecej4 noted (which I note you made) and the program compiles and runs successfully.
C:\u709652> icl /c hapsug.c Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. hapsug.c
C:\u709652> ifort /debug /Od hapsug.obj /exe:findhap4 /static /Qopenmp /check /Qtrapuv /fpe:1 /traceback /warn /reentrancy /D _MYMKL=.TRUE. kinds.f90 findhap4_c.f90 nhash.f90 hapsug.obj Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. findhap4_c.f90(46): remark #7712: This variable has not been used. [K1] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, tot_count --------------------------------------------------------------------------------------------------------------------^ findhap4_c.f90(46): remark #7712: This variable has not been used. [K2] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, tot_count ------------------------------------------------------------------------------------------------------------------------^ findhap4_c.f90(46): remark #7712: This variable has not been used. [INSIDE_COUNTER2] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, tot_count -------------------------------------------------------------------------------- -------------------------------------------------------------^ findhap4_c.f90(48): remark #7712: This variable has not been used. [PRINT_NOW] logical sug_comp_bool, print_now, show_debug ------------------------^ findhap4_c.f90(48): remark #7712: This variable has not been used. [SHOW_DEBUG] logical sug_comp_bool, print_now, show_debug -----------------------------------^ findhap4_c.f90(96): remark #7712: This variable has not been used. [MISSING] integer*1 code(0:35), decode(90), missing/5/ ------------------------------------^ findhap4_c.f90(98): remark #7712: This variable has not been used. [DOMAIN_GET_MAX_THREADS] integer :: domain_get_max_threads, get_max_threads -------------^ findhap4_c.f90(98): remark #7712: This variable has not been used. [GET_MAX_THREADS] integer :: domain_get_max_threads, get_max_threads -------------------------------------^ findhap4_c.f90(102): remark #7712: This variable has not been used. [MATCHCODE] character*2 cthrds, matchcode(7) -----------------------^ findhap4_c.f90(1583): remark #7712: This variable has not been used. [SEG] maxloc, maxhap, nhap, previous, suggest, seg, & ---------------------------------------------^ findhap4_c.f90(1593): remark #7712: This variable has not been used.integer i, j, k, l, ii, new, starti, stopi, hold ------------------^ findhap4_c.f90(1899): remark #7712: This variable has not been used. [MAXCOL] integer start_1, stop_1, start_2, stop_2, i, j, maxcol, col, start_show, end_show ----------------------------------------------------^ Microsoft (R) Incremental Linker Version 14.00.23026.0 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib hapsug.obj kinds.obj findhap4_c.obj nhash.obj
C:\u709652> .\findhap4.exe Output from findhap.f90 version 4 90 40 3 4 1000 10 2 0.07000 0.01000 maxlen,minlen, steps, iters,maxhap,overlap,estfreq,lowdense,errate 30 2 1 2 1 0 0 XChrom,genin,genout,ancout,listout,chip2,useprev Maximum number of processors set to 4 Or set threads by command line argument: findhap4 8 Number of processors available = 4 Can be controlled using: export OMP_NUM_THREADS=8 ... ... <Lots of other output removed> ... ... 325 records written to genotypes.imputed Program findhap.f90 completed normally
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My output for the Fortran code:
Code:
ifort /debug /Od hapsug.obj /exe:findhap4 /static /Qopenmp /check /Qtrapuv /fpe:1 /traceback /warn /reentrancy /D _MYMKL=.TRUE. kinds.f90 findhap4_c.f90 nhash.f90 hapsug.obj
Output:
C:\Gitlabstuff\FindhapScript1>ifort /debug /Od hapsug.obj /exe:findhap4 /static /Qopenmp /check /Qtrapuv /fpe:1 /traceback /warn /reentrancy /D _MYMKL=.TRUE. ki nds.f90 findhap4_c.f90 nhash.f90 hapsug.obj Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. findhap4_c.f90(46): remark #7712: This variable has not been used. [K1] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_ size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, to t_count -------------------------------------------------------------------------------- ------------------------------------^ findhap4_c.f90(46): remark #7712: This variable has not been used. [K2] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_ size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, to t_count -------------------------------------------------------------------------------- ----------------------------------------^ findhap4_c.f90(46): remark #7712: This variable has not been used. [INSIDE_COU NTER2] integer suggest_size, ped_c_size, ped_r_size, sexv_size, keep_c_size, keep_r_ size, PAweight_size, print_counter, k1, k2 , inside_counter, inside_counter2, to t_count -------------------------------------------------------------------------------- -------------------------------------------------------------^ findhap4_c.f90(48): remark #7712: This variable has not been used. [PRINT_NOW] logical sug_comp_bool, print_now, show_debug ------------------------^ findhap4_c.f90(48): remark #7712: This variable has not been used. [SHOW_DEBUG ] logical sug_comp_bool, print_now, show_debug -----------------------------------^ findhap4_c.f90(96): remark #7712: This variable has not been used. [MISSING] integer*1 code(0:35), decode(90), missing/5/ ------------------------------------^ findhap4_c.f90(98): remark #7712: This variable has not been used. [DOMAIN_GET _MAX_THREADS] integer :: domain_get_max_threads, get_max_threads -------------^ findhap4_c.f90(98): remark #7712: This variable has not been used. [GET_MAX_TH READS] integer :: domain_get_max_threads, get_max_threads -------------------------------------^ findhap4_c.f90(102): remark #7712: This variable has not been used. [MATCHCODE ] character*2 cthrds, matchcode(7) -----------------------^ findhap4_c.f90(1583): remark #7712: This variable has not been used. [SEG] maxloc, maxhap, nhap, previous, suggest, seg, & ---------------------------------------------^ findhap4_c.f90(1593): remark #7712: This variable has not been used.integer i, j, k, l, ii, new, starti, stopi, hold ------------------^ findhap4_c.f90(1899): remark #7712: This variable has not been used. [MAXCOL] integer start_1, stop_1, start_2, stop_2, i, j, maxcol, col, start_show, end _show ----------------------------------------------------^ ipo: warning #11010: file format not recognized for C:\Gitlabstuff\FindhapScript 1\hapsug.obj Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib hapsug.obj kinds.obj findhap4_c.obj nhash.obj kinds.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' C:\Gitlabstuff\FindhapScript1>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please note that you are using the 64-bit version of the C/C++ compiler:
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.143 Build 20161005
and the 32-bit version of the Fortran compiler:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 17.0.1.143 Build 20161005
You must use the same version for both languages, or the object files cannot be linked together.
This message from the linker is your clue to the mismatch:
kinds.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Umer Tahir: From these banner lines from the compilers, which I took from #7, you can see the inconsistency:
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32
You can avoid this inconsistency by compiling the C and Fortran parts in the same environment.
Another comment: If you are going to ignore the compiler warnings, why not leave out the -warn option and avoid cluttering up your posts with dozens of warning messages?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for spotting that, I am now starting fresh:
Checking the two compiler versions:
C:\Windows\system32>icl Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi on 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. icl: command line error: no files specified; for help type "icl /help" C:\Windows\system32>ifort Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R ) 64, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. ifort: command line error: no files specified; for help type "ifort /help"
Running my scripts now ..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now it says this:
C:\Gitlabstuff\FindhapScript1>icl Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi on 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. icl: command line error: no files specified; for help type "icl /help" C:\Gitlabstuff\FindhapScript1>icl /c hapsug.c Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi on 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. icl: error #10114: Microsoft Visual C++ not found in path
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I started all on the same environment:
C:\Gitlabstuff\FindhapScript1>icl /c hapsug.c Intel(R) C++ Intel(R) 64 Compiler for applications running on IA-32, Version 17. 0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. hapsug.c C:\Gitlabstuff\FindhapScript1>ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f9 0 hapsug.obj -o findhap4 -static /Qopenmp -C -ftrapuv -fpe1 -traceback -reentran cy -D _MYMKL=.TRUE. -L$MKLPATH -verbose #-heap-arrays Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. ifort: command line warning #10006: ignoring unknown option '/O0' ifort: command line warning #10006: ignoring unknown option '/ftrapuv' ifort: command line warning #10006: ignoring unknown option '/L$MKLPATH' ifort: command line warning #10006: ignoring unknown option '/verbose' ifort: command line warning #10161: unrecognized source type '#-heap-arrays'; ob ject file assumed ipo: error #11018: Cannot open #-heap-arrays Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib kinds.obj findhap4_c.obj nhash.obj hapsug.obj #-heap-arrays LINK : fatal error LNK1181: cannot open input file '#-heap-arrays.obj' C:\Gitlabstuff\FindhapScript1>
If I take out the #-heap-arrays then it compiles fine. Is there any substitute to this?
Compiling fortran code without #-heap-arrays:
C:\Gitlabstuff\FindhapScript1>ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f9 0 hapsug.obj -o findhap4 -static /Qopenmp -C -ftrapuv -fpe1 -traceback -reentran cy -D _MYMKL=.TRUE. -L$MKLPATH -verbose Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. ifort: command line warning #10006: ignoring unknown option '/O0' ifort: command line warning #10006: ignoring unknown option '/ftrapuv' ifort: command line warning #10006: ignoring unknown option '/L$MKLPATH' ifort: command line warning #10006: ignoring unknown option '/verbose' Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib kinds.obj findhap4_c.obj nhash.obj hapsug.obj C:\Gitlabstuff\FindhapScript1>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am now trying to find a solution to the problem reported in #13
Umer Tahir wrote:
Now it says this:
C:\Gitlabstuff\FindhapScript1>icl Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi on 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. icl: command line error: no files specified; for help type "icl /help" C:\Gitlabstuff\FindhapScript1>icl /c hapsug.c Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi on 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. icl: error #10114: Microsoft Visual C++ not found in path
Error:
icl: error #10114: Microsoft Visual C++ not found in path
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was running a command prompt from:
"C:\ProgramFiles(x86)\IntelSWTools\compilers_and_libraries_2017.1.143\windows\mpi\intel64\bin\mpivars.bat"
Now I am using a command prompt from:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" amd64
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The command prompt on VS recognise both icl and ifor x64 versions.
The #head-array issue is still there:
C:\Gitlabstuff\FindhapScript1>ifort -debug -O0 kinds.f90 findhap4_c.f90 nhash.f9 0 hapsug.obj -o findhap4 -static /Qopenmp -C -ftrapuv -fpe1 -traceback -reentran cy -D _MYMKL=.TRUE. -L$MKLPATH -verbose #-heap-arrays Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R ) 64, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. ifort: command line warning #10006: ignoring unknown option '/O0' ifort: command line warning #10006: ignoring unknown option '/ftrapuv' ifort: command line warning #10006: ignoring unknown option '/L$MKLPATH' ifort: command line warning #10006: ignoring unknown option '/verbose' ifort: command line warning #10161: unrecognized source type '#-heap-arrays'; ob ject file assumed ipo: error #11018: Cannot open #-heap-arrays Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib kinds.obj findhap4_c.obj nhash.obj hapsug.obj #-heap-arrays LINK : fatal error LNK1181: cannot open input file '#-heap-arrays.obj'
If I run the way suggested by Kevin D in comment # 8:
C:\Gitlabstuff\FindhapScript1>ifort /debug /Od hapsug.obj /exe:findhap4 /static /Qopenmp /check /Qtrapuv /fpe:1 /traceback /reentrancy /D _MYMKL=.TRUE. kinds.f9 0 findhap4_c.f90 nhash.f90 hapsug.obj Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R ) 64, Version 17.0.1.143 Build 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation. All rights reserved. -out:findhap4.exe -debug -pdb:kinds.pdb -subsystem:console -incremental:no -defaultlib:libiomp5md.lib -nodefaultlib:vcomp.lib -nodefaultlib:vcompd.lib hapsug.obj kinds.obj findhap4_c.obj nhash.obj LINK : fatal error LNK1104: cannot open file 'libiomp5md.lib'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm sorry, I don't understand what you used to set up your command line environment. That might be a clue as to why this isn't working.
That said, my installation of the 17.0U1 kit does have a libiomp5md.lib file, so the problem should not be a missing file.
Windows, unlike Linux/Unix, uses environment variables to help define library paths. Where you used the -L<someDirectoryPath> command line switch on Linux to declare a library path, on Windows it is in the LIB environment variable.
The LIB environment variable is set up in the default command line window created for you by the Parallel Studio XE installation process, or it can also be set by using one of the set up scripts we provide, such as
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.1.143\windows\bin\ipsxe-comp-vars.bat.
(Note; this takes two arguments; it will give you 'usage' info if you neglect to specify them)
If you look at your LIB environment variable, you should have a path something like this in it:
C:\Program Files (x86)\IntelSWTools\parallel_studio_xe_2017.1.040\compilers_and_libraries_2017\windows\compiler\lib\intel64_win
To see your LIB environment variable use:
echo %LIB%
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Lorri Menard,here is what I get when I do echo %LIB%
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>echo %LIB% C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;C:\Program Files (x86 )\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows Kits \10\lib\10.0.10240.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1 \lib\um\x86;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86; C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Clearly, your LIB environment variable contains two components that are unsuitable for 64-bit compilation: they both end in "um\x86". However, the LIB environment variable contains no Fortran library directories, so it appears that you are not using a command window configured for using with Intel Fortran. Perhaps you should tell us the steps that you take before compiling.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
Clearly, your LIB environment variable contains two components that are unsuitable for 64-bit compilation: they both end in "um\x86". However, the LIB environment variable contains no Fortran library directories, so it appears that you are not using a command window configured for using with Intel Fortran. Perhaps you should tell us the steps that you take before compiling.
This is how I am starting my Command Prompt:
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page