I want to install this package on two different machines.
http://www.2decomp.org/download.html
On my Mac laptop, when I am using the Makefile.inc.x86 as my Makefile.inc, and do a make, it works straight away without any problem. But on the other machine when I use the same Makefile.inc file, I am getting the following error:
[k00603#fe01p05 src]$make
mpif90 -DDOUBLE_PREC -O3 -fcray-pointer -cpp -c decomp_2d.f90
gfortran: unrecognized option '-cpp'
Warning: decomp_2d.f90:20: Illegal preprocessor directive
Warning: decomp_2d.f90:21: Illegal preprocessor directive
Warning: decomp_2d.f90:22: Illegal preprocessor directive
Warning: decomp_2d.f90:23: Illegal preprocessor directive
-------------------------------------------------------
--- around 50 more lines with the same warning --------
-------------------------------------------------------
In file decomp_2d.f90:32
integer, parameter, public :: ga_real_type = MT_F_DBL
1
Error: Symbol 'mt_f_dbl' at (1) has no IMPLICIT type
In file decomp_2d.f90:33
integer, parameter, public :: ga_complex_type = MT_F_DCPL
1
Error: Symbol 'mt_f_dcpl' at (1) has no IMPLICIT type
In file decomp_2d.f90:36
-------------------------------------------------------
------------ a lot of other errors --------------------
-------------------------------------------------------
Both of them are Linux x86_64 machines. Any ideas what can I do to install it on the other machine?
Your gfortran is probably too old. -cpp option was added in 2008. Get a new one, or try -x f95-cpp-input or -x f77-cpp-input istead.
To guarantee preprocessing, you could rename decomp_2d.f90 to decomp_2d.F90. I know -cpp should already guarantee it, but it may be worth a try since we don't necessarily know what the underlying compiler is.
Related
I am trying to compile a f77 file (dfsynthe.for) using gfortran.
Before that I tryed to compile it using ifort by ifort -double-size 64 -save -o dfsynthe.exe dfsynthe.for, and it worked.
However when I tried using gfortran by gfortran -std=legacy -fdec -w -o dfsynthe.exe dfsynthe.for I got a bunch or errors. I assume that there are some differences in the syntax when using gfortran and ifort, but I have no idea what exactly they are.
My ifort version is ifort (IFORT) 19.0.3.199 20190206 and gfortran version is GNU Fortran (Ubuntu 8.3.0-6ubuntu1~18.10.1) 8.3.0.
The errors I got from gfortran are mainly in five types:
dfsynthe.for:135:51:
OPEN(UNIT=15,STATUS='NEW',FORM='UNFORMATTED',
1
Error: Syntax error in OPEN statement at (1)
dfsynthe.for:434:20:
CLOSE(UNIT=12,DISP='DELETE')
1
Error: Syntax error in CLOSE statement at (1)
dfsynthe.for:475:11:
2 3046.604,2238.320,1713.711,1354.044,1096.776,
1
Error: Syntax error in DATA statement at (1)
dfsynthe.for:3225:29:
969 IF(T.GE.5000.)GO TO 979
1
Error: Label 979 referenced at (1) is never defined
dfsynthe.for:2327:48:
EQUIVALENCE (D(21),D5(1)),(D(26),D6(1)),(D(31),D7(1))
1
Error: Rank mismatch in array reference at (1) (1/2)
Here is the link for dfsynthe.for and the error log file error.log.
You may have the lines offset by 1 space or more. It appears you are trying to run old Fortran legacy code. Nothing wrong with that and it should run using Gfortran. Check your source code and confirm all statements start in column seven. If a line has a line number, as in 1000 continue be sure line number is in columns 2-6. If this still doesn't work or source code is formatted properly leave a note in the comments telling what you learned.
You might try renaming the file to dfsynthe.F77 and seeing how that works.
You have some tabs in the source file. Replace them with spaces and you will get a little farther.
I downloaded elfutils 0.170 and 0.169, but can't use gcc to compile either of them because of implicit-function-declaration. I can't find any place in elfutils makefile which specifies -Werror or -Werror=implicit-function-declaration. Any idea to fix this compilation error?
https://sourceware.org/elfutils/ftp/0.170/
My steps
1: bzip2 -d elfutils-0.170.tar.bz2
2: tar -xvf elfutils-0.170.tar
3: ./configure
4: make
Then below errors show up.
elf_compress_gnu.c: In function 'elf_compress_gnu':
elf_compress_gnu.c:114:28: error: implicit declaration of function 'htobe64' [-Werror=implicit-function-declaration]
uint64_t be64_size = htobe64 (orig_size);
^
elf_compress_gnu.c:163:15: error: implicit declaration of function 'be64toh' [-Werror=implicit-function-declaration]
gsize = be64toh (gsize);
^
cc1: all warnings being treated as errors
elfutils incorrectly uses htobe64, which is not in any standard and only available in glibc and a subset of the BSDs.
Since you use GCC, you can use Ulf Hermann's patch to work around this issue:
Add replacement endian.h and byteswap.h to libgnu
It adds an implementation of htobe64 based on GCC built-in functions, so it is available when GCC is used as the compiler, independently of what the C library provides.
I am trying to migrate a .FOR file (for practice purposes) from ifort to gfortran. This file compiles in my Intel Visual Fortran solution with no issues. However when I compile it in gfortran using the following command:
gfortran -ffree-form -ffree-line-length-200 -Dinternal_debug -c MyFile.FOR -o MyFile.o
I get the following error message:
MyFile.FOR:4561:22:
102 format(A, I)
1
Error: Nonnegative width required in format string at (1)
Does ifort simply not require there to be a format width or are there additional ifort options that enable relaxing this requirement? How come the file runs smoothly in ifort but not in gfortran?
Your observation is correct, I have encountered this myself before. Intel Fortran does not enforce this requirement while gfortran does. The field width is actually required by the Fortran standard. I am not aware of any compiler option that could change this behaviour. The only option I am aware of is to fix the code to make it standard compliant.
How to do it can be found in Error: Nonnegative width required in format string at (1) . Note that the g0 that you asked about is not a compiler option to accept I. It is a different format descriptor to put into the code instead of I.
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
First some background - I have three VS2010 C++/OpenCL projects that compile and run fine on Windows 7 64-bit. I've been trying to compile and run each of them on Linux 64-bit (Ubuntu/Debian). The first two are compiling and running on linux and don't really use any external libraries. The third uses only Boost 1.50.0 and isn't compiling using the same method as the first two. So first let me go through what I did to get the first two to work.
I extracted only the source from the myriad of folders.
I ported windows specific code to linux specific code.
I wrote a bash script to generate the g++ command with all sources to compile them.
I ran the compile script to generate an output target file.
The bash script is as follows.
#!/bin/bash
SOURCE=""
for i in `ls *.h *.cpp *.hpp`; do
SOURCE+="${i} "
done
COMMAND="g++ -I/home/junkie/downloads/boost_1_51_0 -o out ${SOURCE} -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive"
echo -e "\n"
echo -e "${COMMAND}"
echo -e "\n"
$COMMAND
exit $?
And it generates and runs a command similar to following.
g++ -I/home/junkie/downloads/boost_1_51_0 -o out blah.cpp blah.h foo.hpp baz.cpp etc.cpp -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive
I compile using the following command.
./compile.sh &> log; echo $?; grep -ci error log; wc -l log
Now you may be wondering why I've adopted such unconventional and redundant means of getting a C++ project to compile and run on linux. Well because I'm new to the linux c and c++ toolchain and this was the quickest and simplest route I could figure out to get the job done and it did get the first two projects up and running. However, the third uses boost and this method isn't working and I need your help in figuring out what all these strange errors are.
The errors I'm getting are not actually from the project code but instead from Boost and AMD's opencl libraries code which is strange because the other projects were using opencl too and those worked fine.
Some examples of boost errors are below.
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
In file included from main.cpp:4:
foo2.hpp:1610:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void /home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp: At global scope:
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected unqualified-id at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
Some examples of opencl errors are below.
In file included from /opt/AMDAPP/include/CL/cl_platform.h:35,
from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/usr/include/stdint.h:49: error: expected ‘;’ before ‘typedef’
In file included from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/opt/AMDAPP/include/CL/cl_platform.h:41: error: expected unqualified-id before string constant
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected unqualified-id at end of input
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected ‘}’ at end of input
The boost includes I'm Using are as follows.
#include <boost/preprocessor/punctuation/paren.hpp>
#include <boost/preprocessor/punctuation/comma.hpp>
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
#include <boost/type_traits/is_base_of.hpp>
#include <boost/mpl/not.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/logical.hpp>
#include <boost/mpl/eval_if.hpp>
#include <boost/mpl/identity.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/array.hpp>
So, finally, my questions are as follows.
1) What is the root cause of these errors in light of the building method I'm using and how do I resolve this problem? Does order of files or library inclusion matter? I'm using a local source download of boost as part of my g++ command as instructed by boost documentation rather than prebuilt binaries as I'm not using anything that requires prebuilt binaries.
2) I realise that my way of building things is pretty primitive. I'm learning make and I've seen some recommendations to use cmake and kdevelop which I need to look into. The primary problem with using make is that these projects weren't written with make in mind so I'm not aware of the dependency graph between source files to create the makefile (if I'm thinking correctly; I'm still fairly new to it). If you have any recommendations of how to do things better please do enlighten me.
Thanks.
I finally managed to overcome this problem and here I provide a brief account of how. To be clear I don't know what the root cause of the original problem was. In other words - I don't know why the problem occurred. All I'm saying is that my workaround allowed me to resolve the issue and move onto other problems (compile time errors).
Essentially, to reiterate, the problem was that for whatever reason a project using boost wasn't compiling on Linux because all instances of the use of the BOOST_PP_CAT() function produced the following error.
error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
For whatever reason the compiler wasn't able to correctly process the use of this function but was able to process the use of other boost functions such as BOOST_PP_LPAREN(), BOOST_PP_RPAREN() and BOOST_PP_COMMA. The problem looked almost certainly related to the preprocessing stage where the combined use of the aforementioned boost functions was resulting in an unterminated argument list.
To elaborate on the nature of the relevant code (which was not written by me thankfully) the prior developers had essentially used boost preprocessor functions to create a DSL that they could then re-use multiple times to generate a list of functions. It would have seemed a lot easier to me to simply write the functions directly but anyway that's another concern.
My work around was to change the relevant section of code so that it didn't use any BOOST_PP_CAT() functions but ultimately defined the exact same functions as before. I did this by substituting the use of BOOST_PP_CAT() with the code that was being generated by it. This overcame all instances of the error quoted above but left me with hundreds of other compile time errors in my efforts to migrate this project from windows to linux.
Although this was a very specific and unusual question with an equally specific and unusual answer I wanted to feed this back to dispel the mystery behind this problem. As to why this particular function was failing to preprocess/compile on linux but passing on Windows I don't know but would very much like to know. I can only assume it is a fundamental difference in the way VC++ performs preprocessing as opposed to g++ and clang or more specifically perhaps a difference in the order of resolution of nested functions in preprocessor directives. Who knows. Anyway, thanks for your help guys.
The unterminated argument list invoking macro error suggests a lacking closing parenthesis. Use your editor's parenthesis matcher to check it. Be sure that your source files are in Unix format, not in DOS format (e.g. with \n à la Unix, not with\r\n à la MSDOS, at each end-of-line). Use dos2unix if needed.
Otherwise, don't forget that you can run g++ -Wall -C -E -H -I/home/junkie/downloads/boost_1_51_0 yoursourcecode.cc to get the preprocessed form of yoursourcecode.cc, and, by redirecting that command, you can inspect that preprocessed form with the editor of your choice (like emacs).
As I commented, learn to use Gnu make (and if in trouble debugging your Makefile, which you should edit with a good editor like emacs, use remake -x to debug it).
And the -I/home/junkie/downloads/boost_1_51_0 looks very suspicious: even if Boost is often a header only library, it has, as far as I remember, an installation procedure on Unix (and Linux distributions often package Boost libs). You should install your Boost libraries as documented (and after having configured them), and likewise for OpenCL.