I am trying to compile a big solver using a makefile. When typing make, the following command gets executed:
mpif90 -O2 -fpp -I/somePath/ -c precision.F90
I get the following error:
gfortran: error: unrecognized command line option ‘-fpp’
I typed which mpif90 to see where it is pointing to:
/usr/local/intel14/impi/4.1.3.048/intel64/bin/mpif90
I tried to manually enter the command to make sure it did not have anything to do with the makefile and I got the same error. Why is gfortran being called? It must be some linking error but I can't figure it out.
The comments put me on the right track. I did not know mpif90 was just a wrapper.
$ /usr/local/inter14/impi/4.1.3.048/intel64/bin/mpif90 -v
mpif90 for the Intel(R) MPI Library 4.1 for Linux*
Copyright(C) 2003-2014, Intel Corporation. All rights reserved.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc5.2/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc5.2 --disable-multilib
Thread model: posix
gcc version 5.2.0 (GCC)
I asked the code's author to do the same, the output pointed to an intel compiler. So what remains is to link ifort. This fixed it for me (bash shell):
export I_MPI_F90=ifort
You can just use the alternative
/usr/local/intel14/impi/4.1.3.048/intel64/bin/mpiifort
Related
I have two GCC compilers installed on a Linux (CentOS) machine. The old version of GCC (4.4.7) is in the default folder (came with CentOS) and the newer one that I intend to use is in /usr/local/gcc/4.9.3/. My code utilizes MPI and LAPACK/LAPACKE/BLAS libraries and with the old GCC I used to compile source (for example “main.cpp”) like this:
mpiCC main.cpp -o main -L/home/USER1/lapack-3.6.1 -llapacke -llapack -lblas -lm –Wall
This still invokes the old GCC 4.4.7. What should I modify so the above MPI compilation (mpiCC) invokes GCC 4.9.3 executable from the new location at /usr/local/gcc/4.9.3/el6/bin/ ?
From MPICH Installer's Guide version 3.2 (page 6):
"The MPICH configure step will attempt to find the C, C++, and Fortran compilers for you, but if you either want to override the default or need to specify a compiler that configure doesn't recognize, you can specify them on the command line [...]. For example, to select the Intel compilers instead of the GNU compilers on a system with both, use"
./configure CC=icc CXX=icpc F77=ifort FC=ifort ...
Is there a way to dicriminate between different version of GCC compilers in ./configure ?
I guess mpiCC uses the first gcc compiler found in the $PATH variable.
You should be able to set the new version of gcc by running:
PATH="/usr/local/gcc/4.9.3/el6/bin:$PATH" mpiCC main.cpp -o main -L/home/USER1/lapack-3.6.1 -llapacke -llapack -lblas -lm –Wall
If you really want two versions of GCC installed at the same time and use both of them here is a good link that explains how to do this:
http://gcc.gnu.org/faq.html#multiple
Finally found how. Here is the recipe:
1) check your if you shell is bash, if not set it to bash: $ echo $SHELL
/bin/tcsh
It was tcsh and needed to be set to bash.
2) Switch to bash: $ bash
bash-4.1$
3) Add new version of GCC to the front of the PATH:
bash-4.1$ export PATH=/usr/local/gcc/4.9.3/el6/bin:$PATH
4) Check the PATH: bash-4.1$ echo $PATH
/usr/local/gcc/4.9.3/el6/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin
5) Check version of GCC used (It picks up the first GCC from the PATH):
bash-4.1$ gcc --version
gcc (GCC) 4.9.3
Note: this is just for the current session.
I have just started my work with FORTRAN and I want to compile a program. This is what I'm receiving from compiler after writing make in command line.
mpif77 -c -mcmodel=medium -i-dynamic -no-ipo -r8 -xW -traceback -O2 ../agile/agile_parameter_module.f
gfortran: error: unrecognized command line option ‘-i-dynamic’
gfortran: error: unrecognized command line option ‘-no-ipo’
gfortran: error: unrecognized command line option ‘-r8’
gfortran: error: unrecognized command line option ‘-traceback’
I have downloaded and install trial version of Intel Fortran Compiler but make still uses gfortran and I got that message.
The mpif77 wrapper you are using has been configured for gfortran, which does not understand options for ifort. If you don't have the cluster tools for Intel Fortran you won't have their MPI wrapper mpiifort and will have to configure openmpi to use ifort.
If you want to avoid compiling openmpi to set it up for ifort you can try to use the MPI wrapper for gfortran with ifort like this:
ifort <ifort command line arguments> `mpif77 -showme:compile`
for the compile steps and
ifort <ifrot command line arguments> `mpif77 -showme:link`
for the link steps.
If those don't work directly you can look at the options emitted by mpif77 and modify them for ifort as needed. This is a stop-gap solution just to get your software built but for a long term solution you should properly set up openmpi to use ifort.
I have a program running on many different linux distros. When I compile it on FreeBSD 10.1 for some reason the catch clauses stop working and exceptions that should get caught crash my program. When debugging I modified one of the catch clauses to "catch (...)" and still the exception wasn't caught. I guess the issue is related to the linker, but I don't know how to debug it futher. When I tried compiling a test program that simply throws and catches and exception it worked - so I guess the linker fails to link the different objects properly.
Anyone know how can I solve it?
Thanks
EDIT:
compilation examples (original paths in the commands are longer, deleted them for clarity):
I compiled many classes like this:
/usr/local/bin/g++ -O3 -c -DFreeBSD -D_FreeBSD -I. -I/usr/local/openjdk8/include -I/usr/local/openjdk8/include/freebsd -DBOOL_DEFINED -D_BOOL -DFreeBSD -fPIC -I../../../../common/cpp -DVERSION_MAJOR=8 -DVERSION_MIDDLE=2 -DVERSION_MINOR=8 -DNSC_DEBUG -DUSE_HINT_FILES -o CNBCommand.o CNBCommand.cpp
then create an archive with
ar srv "bin/FreeBSD_10.1-RELEASE/mechanism.a" <many .o files compiled like above>
And the final executable is linked with:
/usr/local/bin/g++ -O3 -B/usr/local/bin -rpath=/usr/local/lib -lstdc++ -lpthread -o "../bin/FreeBSD_10.1-RELEASE/nbstatus" <many *.o files compiled like above> bin/FreeBSD_10.1-RELEASE/mechanism.a
This is the g++ I use:
/usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd10.1/4.9.3/lto-wrapper
Target: x86_64-portbld-freebsd10.1
Configured with: ./../gcc-4.9-20141126/configure --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 --build=x86_64-portbld-freebsd10.1
Thread model: posix
gcc version 4.9.3 20141126 (prerelease) (FreeBSD Ports Collection)
You have to link with -Wl,-rpath=/usr/local/lib/gcc<VERSION> or you'll link against libc++, which doesn't match the headers gcc uses.
Check pkg info -Dx gcc for the right path.
I am trying to install PARI/GP and in the configuration step I get:
$ ./Configure
[...]
Looking for the compilers ...
...cc is /usr/bin/cc
...gcc is /usr/local/bin/gcc
GNU compiler version 4.8.0 20120705 (experimental) (GCC)
###
### C compiler does not work. PARI/GP requires an ANSI C compiler! Aborting.
###
### Compiler was: /usr/local/bin/gcc
$ gcc --version
gcc (GCC) 4.8.0 20120705 (experimental)
This is strange because the documentation says:
"Only ANSI C and C++ compilers are supported. Choosing the GNU compiler
gcc/g++ enables the inlining of kernel routines (about 20% speedup; if you
use g++, it is a good idea to include the -fpermissive flag). If you choose
not to use gcc, the C++ version of Pari will be a little faster because of
general inlining, but can be used in library mode only with C++ programs.
We strongly recommand using gcc all the way through."
I have also tried with g++ with the same result.
I am trying to compile on a linux x86_64.
Any ideas?
Thanks in advance,
M;
The config/get_cc script in PARI's top level tried to compile a test program
and failed.
Look for the line
$CC $CFLAGS $extraflag -o $exe ansi.c 2>/dev/null && $RUNTEST $exe
and remove the 2>/dev/null. Configure should now print out explicit error
messages from the compiler. They should provide a hint.
I had the same problem. Here is the solution for Linux Mint 17.1 64-bit:
sudo apt-get install gcc libc6-dev libgmp-dev
This command also installs the GMP library (recommended for PARI/GP).
Thanks to K.B. for the hint on how to see the problem.
The problem
I am trying to build SRI's Language Modeling tool, srilm version 1.6.0 on my mac, and coming across some fairly strange compilation problems ("strange" in that a few hours of Google-fu did not help), so I am turning to you to see if anyone sees how I can fix this.
I have already checked that I have the required dependencies and followed the install instructions as well as gone through the build troubleshooting section of the FAQ.
System Specifications
I have a pretty vanilla install of OS X, with some packages installed through homebrew. XCode 4.3.2 (latest version) is installed. Here are the other relevant system details.
OS version
Mac OS X 10.7.4
gcc -v printout
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.0.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.6.1/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.6.1 (GCC)
g++ -v printout
$ gcc -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.0.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.6.1/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.6.1 (GCC)
uname -a printout
$ uname -a
Darwin MacBook-Air.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
The error itself
The following is the end of the output produced by running make World from the srlim top-level directory. Everything up until this point compiles fine in any of the following circumstances:
I run make World on its own.
I run make World MACHINE_TYPE=macosx
I run make World MACHINE_TYPE=macosx-m64 (specific makefile for 64bit processors)
I run make World MACHINE_TYPE=macosx-m32 (specific makefile for 32bit processors)
And the error that pops up is always the same (shown below).
stderr printout
$ make World
(...) # a bunch of stuff compiles with no errors or warnings
c++ -Wreturn-type -Wimplicit -DINSTANTIATE_TEMPLATES -DHAVE_ZOPEN -I/usr/include -I. -I../../include -DHAVE_ZOPEN -c -g -O2 -fno-common -o ../obj/macosx/LatticeIndex.o LatticeIndex.cc
LatticeIndex.cc:78:6: error: variable length array of non-POD element type
'NBestWordInfo'
makeArray(NBestWordInfo, roundedNgram, len + 1);
^
../../include/Array.h:93:33: note: expanded from macro 'makeArray'
# define makeArray(T, A, n) T A[n]
^
LatticeIndex.cc:126:4: warning: data argument not used by format string
[-Wformat-extra-args]
(float)ngram[0].start);
^
LatticeIndex.cc:128:4: warning: data argument not used by format string
[-Wformat-extra-args]
(float)(ngram[len-1].start + ngram[len-1].duration));
^
2 warnings and 1 error generated.
make[2]: *** [../obj/macosx/LatticeIndex.o] Error 1
make[1]: *** [release-libraries] Error 1
make: *** [World] Error 2
Any idea what could be going wrong? It seems to compile fine on some other people's macs in my department, and I've checked their makefiles for differences, but nothing popped up. No one here has any idea why the build fails, but we'd really appreciate it if you can help us out. Thanks in advance for any help you can provide me with! :-)
The problem is due to Apple using llvm-gcc/clang, which does not support variable length arrays. This problem can actually be addressed by modifying $SRILM/dstruct/src/Array.h, and has been noted and addressed in the upcoming release of srilm.
For the time being, on a mac, build srilm using g++ 4.2 instead, using the following command:
$ make MACHINE_TYPE=macosx-m64 CXX=g++-4.2 World
This builds srilm without problem on all my macs.