Trying to make work MKL_Pardiso on MacOS. I installed Intell Parallel Studio and compile program with fort.
include 'mkl.fi'
INCLUDE 'mkl_pardiso.f90'
program temp
use mkl_pardiso
end program temp
Here is my code to compilier
ifort -mkl temp.f90
The output is
/opt/intel/compilers_and_libraries_2020.1.216/mac/mkl/include/mkl_pardiso.f90(26): error #6218: This statement is positioned incorrectly and/or has syntax errors.
MODULE MKL_PARDISO_PRIVATE
Why does this happen? should I use another flags?
please try build as follows: ifort -mkl mkl_pardiso.f90 temp.f90
Related
I am encountering issues when trying to compile fortran code using meson build system on an HPC cluster.
On the cluster, I am using Intel compiler suite. The meson compile command aborts at the linking step with:
ld: /usr/bin/../lib64/crt1.o: in function `_start':
(.text+0x20): undefined reference to `main'
ninja: build stopped: subcommand failed.
The interesting thing is that the link command issued by meson is something like this:
icpc -o main main.p/somefile.o ..., so it is using Intel's C++ compiler to link my fortran code. I tried to use the exact same command line, replacing icpc with ifort and adding -lstdc++. That actually worked.
So, I wonder, is there a way to force Meson to link my code with ifort, instead of icpc? Or, should I do something else?
I am afrad I cannot share the code at this moment. But, I'm open to showing bits and pieces of the meson.build file(s), if needed.
Details
The codebase consists of fortran source and a CMake C++ subproject; Essentially, the C++ subproject is a wrapper for OpenCV image plotting functions. This is why I needed to add -lstdc++ to my successful manual link command above.
Meson version: 0.55.3
Intel Fortran compiler: ifort (IFORT) 19.1.3.304 20200925
Intel C++ compiler: icpc (ICC) 19.1.3.304 20200925
The code is MPI parallelised.
The same code compiles well with GNU compilers v10 on a normal workstation.
Meson is not going to do any hand-holding when it comes to mixing languages. Here is what I found out works for Intel compilers:
fc=meson.get_compiler('fortran')
# cxx=meson.get_compiler('cpp')
...
if (fc.get_id() == 'intel')
#if (cxx.get_id() == 'intel')
...
add_global_link_arguments('-cxxlib',language : 'fortran')
add_global_link_arguments('-nofor_main', language : 'cpp')
endif
...
executable('myprog','myprog.f90', ..., link_language : 'fortran')
#executable('myprog','myprog.f90',...)
Sort briefing what I am trying to do:
I want to use vnode-lp on my windows PC. I’ve installed MinGW. I’ve installed the necessary dependencies like LAPACK & BLAS libraries as well as Profil/BIAS. The installation of all libraries passed the make and make install process without errors. I hope (!) I’ve managed to install it correctly.
Now the Problem:
Now I’ve tried to get a simple program compiled with basically northing in it just an #include “vnode.h”. First I tried it with Microsoft Visual Studio. Since this gave me several errors I tried to compile it with g++ using MinGW. This gives me the same errors. It starts with
./matrix.w:90:17: error: ‘v_bias’ is not a namespace-name
The Question:
How to include vnodelp into an c++ program and compile it without errors under windows, am I missing something?
Off-topic:
I am trying to get this running for over a week now and don’t know what to do anymore.
C++ is most definitely not C, and packages designed for C++ will never compile and run as C code. So, what you're trying to do really can't be done unless you do some fancy stuff by creating a .dll or something like that, and even then I think you wouldn't get the functionality you want. Why not write your code in C++ and compile with g++ or a similar compiler?
I have managed to finally solve this issue. In case someone has the same problem here is the solution.
I have missed something in the call. Here is the full call that has worked for me:
g++ -o2 –Wall –Wno-deprecated –DNDEBUG – DPROFIL_VNODE – DMAXORDER=50 –I(path to profil bias)/include –I(path to profil bias)/include/BIAS –I(path to profil bias)/src/Base –I(path to vnodelp)/FADBAD++ -I../include –DNDEBUG –c –o (filename).o (filename).cc
g++ -L(path to profil bias)/lib –L(path to lapack)/lib –L../lib –o (filename) (filename).o –lvnode –lProfil –lBias –llr (path to lapack)/lib/liblapack.lib (path to lapack)/lib/libblas.lib –lstd++
funfact:
This also complies with gcc instead of g++
I am new to using the Math Kernel Library(mkl). I have a program that uses a system-of-linear-equations-solver( gesv routine) of LAPACK (which comes with MKL). I already have MKL (also Intel Parallel Studio XE) installed on my computer. I am having trouble compiling/linking the code. I compile the code using:
ifort -mkl matrixinv.f90
However, it gives the following error
/tmp/ifortjcXZTm.o: In function `MAIN__':
matrixinv.f90:(.text+0xdf): undefined reference to `gesv_'
The code is attached below
PROGRAM matrixinv
IMPLICIT NONE
REAL(8),DIMENSION(3,3)::A,C
INTEGER(4),DIMENSION(3)::IPVT
REAL(8)::RCOND
REAL(8),DIMENSION(3)::V,B
A(1,1)=3.0_8
A(1,2)=2.0_8
A(1,3)=-1.0_8
A(2,1)=2.0_8
A(2,2)=-2.0_8
A(2,3)=4.0_8
A(3,1)=-1.0_8
A(3,2)=0.5_8
A(3,3)=-1.0_8
B(1)=1.0_8
B(2)=-2.0_8
B(3)=0.0_8
call gesv(A,B)
PRINT*,B
END PROGRAM matrixinv
You probably want to declare gesv as external. Add the following statement after the "implicit none":
external gesv
This is simple fortran90 program testing MPI.
I would like to compile it on MS Windows platform using MinGW64 Fortran and the known MS-MPI package.
However, it's not working due to missing "mpi.mod". When I replace the use mpi with include 'mpif.h', it's giving other errors (below).
Any help, please ? Does the MS-MPI suite cooperate with the MinGW gfortran ?
PS1:
Working with MS-MPI and MinGW gfortran is not an easy task, https://social.microsoft.com/Forums/en-US/245dcda4-7699-494f-bbe1-b76eb19e53da/linking-msmpi-with-mingw-gfortran?forum=windowshpcmpi
C:\Users\milias\Documents\Dirac\software\autocmake-devel\ms-mpi>gfortran -fno- range-check -c example.f90
mpif.h:344.38:
Included at example.f90:4:
PARAMETER (MPI_AINT=z'4c00043b')
1
Error: PARAMETER attribute of 'mpi_aint' conflicts with PARAMETER attribute at (1)
mpif.h:359.35:
Included at example.f90:4:
PARAMETER (MPI_ADDRESS_KIND=INT_PTR_KIND())
1
Error: Function 'int_ptr_kind' in initialization expression at (1) must be an intrinsic function
solved here, I apologize for the duplicate.
https://github.com/scisoft/autocmake/issues/85#issue-102874399
I recently started using CodeBlocks and began encountering odd runtime errors which I have traced back to printing strings using cout <<. For example, even the following..
#include <string>
#include <iostream>
int main()
{
std::string str;
str = "Hi!";
std::cout << str << std::endl;
return 0;
}
results in an error. It will compile fine (using Borland) but when I run it I get a pop up window saying 'test.exe has stopped working' and in the console I get the message:
Process returned -1073741819 (0xC0000005) execution time : 1.526 s
Press any key to continue.
It compiles and runs fine in MS Visual C++ and with G++ in Ubuntu.. any thoughts would be greatly appreciated!
Cheers,
Weatherwax
My one-off comment ended up helping solve the problem so here it is packaged up as an answer for future users:
This guy had a similar issue and it ended up being a linker issue which he
fixed. The fix is the last post in the thread, although reading the
whole thread could be useful for you.
Long Story short: Borland compiler is a bit dated and annoying to use. Ended up being a linker issue within borland. Better off using a different compiler like GCC/G++ or Visual Studio compiler.
This answer is here to elaborate on the root cause of the issue.
The reason for your crashing program is because the wrong runtime library is being linked. Specifically, your example is compiled as a single threaded object file(the default) but the linking step is using the multithreaded cw32mt.lib runtime -- the "mt" suffix at the end means multithreaded.
The solution is to make sure the runtime your program is compiled to use matches with the runtime you're linking against. A few ways to do this.
Important bcc32 compile switches:
-tW Windows GUI program. WinMain() is expected
-tWC Windows Console program. main() is expected. default.
-tWR Use dynamically linked runtime. Absence implies static runtime linkage.
-tWM Use multithreaded runtime. Absence implies single thread.
Compiling your example program as single threaded like this works:
bcc32 -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32.lib import32.lib,,
or you can compile it as multithreaded like this(note the -tWM switch matching up with cw32mt.lib):
bcc32 -tWM -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32mt.lib import32.lib,,
A third approach that is easier and less error prone is to not call the linker yourself. Instead, let the compiler drive the linker indirectly(similar to gcc):
bcc32 -tWM -oexample.obj -c example.cpp
bcc32 -tWM example.obj -eexample.exe
For your simple example, it can even be shortened to:
bcc32 -eexample.exe example.cpp
Lastly, you can pass the -tW switch multiple times. For example, this command compiles your example as a console program with multithread support and dynamic runtime linkage:
bcc32 -tWM -tWR -tWC -eexample.exe example.cpp
The produced example.exe executable is much smaller and its import table has an entry for CC3250MT.DLL confirming that the borland runtime is dynamically linked.
We should not assume that a non-functioning program is caused by nonconformity to the standard or a bug in the tool we're using without first investigating user error as a potential cause (even though in this case it's tempting to do so). In the OP's case, the code::block IDE didn't have the right commands setup for the toolchain being used.