I am using a bash shell on my Mac OS X. I have fortran95 compiler installed in /sw/bin/gfortran. every time I attempt to access the compiler, I receive
the error:
"Segmentation fault: 11". I cannot call any programs the regular way
i.e. "gfortran program.f90 -o executable_name "
I am not sure about the problem. Even simple programs which print "hello world" to screen will not work.
May be a problem with your installation as already mentioned. A couple things I would try:
Make sure the shared libraries it is compiled against are being found:
otool -L /sw/bin/gfortran
Compile with some switches that might give you more helpful info. I found using the backtrace option really helps especially to debug seg. faults. You might try to compile with some options such as:
gfortran -g -fbounds-check -Wall -fbacktrace program.f90
Related
I am trying to compile a code with crayftn.
I get an error message
/opt/cray/pe/cce/10.0.1/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld: failed to convert GOTPCREL relocation; relink with --no-relax
So it wants the flag --no-relax? OK, I can do that. So I re-link with that flag, and then it tells me
ftn -O3 --no-relax -dynamic -h pic -h omp -o stream_cray stream_mpi.o mysecond.o
ftn-2115 crayftn: ERROR in command line
"-no-relax" is an invalid command-line option.
So it asks for "--no-relax", but then it doesn't understand it. Anyone know of a way out of this conundrum? Or another way of solving the root problem in the first place?
I found this link:
https://bb.cgd.ucar.edu/cesm/threads/failed-to-convert-gotpcrel-relocation-relink-with-no-relax.4494/
PROBLEM:
Hi, I get the following error message for CLM5.0 compilation with
Intel compilers, during the final cesm bld ..ld: failed to convert GOTPCREL relocation; relink with --no-relax
SOLUTION:
Hi, Seems like found a solution to fix the compilation ...Adding of
"-Wl,--no-relax" in LDFLAGS does not solve this problem, but
"-mcmodel medium" in FFLAGS fixes this issue, after searching for
"Relocation truncated to fit" in google search engine, it comes up
with this link which was helpful to solve the issue
"https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268394"
Best Regards,Prabhakar
See also:
https://community.intel.com/t5/Intel-Fortran-Compiler/relocation-truncated-to-fit/td-p/1146616
This looks like mixing compilers and libraries from different systems
mixed up, either 32bit vs. 64bit or installations for ifort and
mpiifort based on different glibc or something similar.
I'm still curious about your "development environment":
Q: Have you been able to successfully compile, link and run ANY
program with your crayftn? Q: What version of crayftn? 10.0.1? Q: What
platform? Where is x86_64-pc-linux coming from? Just curious...
I have a little bit starnge question. Im started to programing Raspi, and i would like to compile my code on the target Pi. If i make it manually i can compile it, but the netbeans(version 8) give me fault for the remote compile.
gcc -o file file.c -lbcm2835 thats how i need to compile. Or g++.
Here is a little bit codesnap from the output with the error. [http://codepaste.net/fygdpj][1]
Please let me allow to ask some help with this situation, oh yes the bcm2835.h is in the /usr/local/include
Regards
I'm a noob, I admit it. Regardless, I've had a really annoying problem with MinGW.... I can write AND compile programs in C with no problem whatsoever, but recently I've tried to install Cmake, but I can't because it fails every time it tests the C++ compiler (g++). So that lead me to just write a simple "hello world" program in C++ and try to compile it. No dice. Again and again I get no response whatsoever. On the command line, I'm typing
g++ -o hello++.cpp hello++
but have also tried
g++ -o hello++.cxx hello++
g++ -o hello++.cc hello++
g++ -o hello++ hello++.cpp
(Of course I saved copies of the source code in the same directory with the .cxx and .cc extensions respectively)
and a bunch of other combinations thereof. Everytime I get nothing. No warning. No error. Nothing. No .exe file was created in the directory, and typing "hello++" on the command line afterwards just gives me a "command not found" error. Soooo.... what the hell is going on? Why does the gcc command work but the g++ not?
I'm on windows 8, using cygwin.
The last one should have succeeded; you won't get a message saying it's succeeded, but you should see the executable in the current directory. The others all try to take the executable as input and output the source, which won't work; although I'm surprised you don't get error messages.
If it did succeed, then simply typing hello++ is unlikely to run it since the current directory is typically not on the path. Try ./hello++ instead.
If it didn't succeed, then it's possible that g++ isn't installed properly. I'm afraid I've no idea how to fix a broken Cygwin installation. Perhaps which g++, to see which program is actually being run, might give some clues.
I'm running on Mac OSX, version 10.8.5 (Mountain Lion). I have the following simple C++ code.
main.cpp:
#include <iostream>
int main ()
{
std::cout << "Hello world!"<<std::endl;
std::cout << "Goodbye world!"<<std::endl;
return 0;
}
I'm trying to get gprof to work on my computer. As the manual suggests, I enter the following two lines into my terminal:
g++ -g -pg main.cpp -o a.out
./a.out
However this does not generate a gmon.out file as it is supposed to. When I try typing gprof in the terminal, it says:
gprof: can't open: gmon.out (No such file or directory)
which is to be expected since gmon.out isn't there...
Any ideas on what I'm doing wrong?
EDIT: Some other things that may help:
My friend, who has a similar OS X version (I can ask him later to confirm), and the exact same versions of g++ and gprof, was able to
use gprof successfully as I have outlined.
I'm using an older version of g++ but I have read online that updating to a newer version didn't help.
a.out works perfectly, it prints out Hello world! and Goodbye world!. I also tried this with a more complex C++ program with
several classes and it still has the same problem. Everything
compiles and runs normally but no gmon.out file is produced.
You have to realize that OS X/MacOS does not provide GNU GCC on the system by default.
Note the output of this command:
ls -la /usr/bin/g++ /usr/bin/clang++
These executables look identical. (Actually! It looks like they are different, but somehow the filesize is identical!)
As far as I can tell, clang doesn't support the production of gprof output. As confusing as it may be, the gcc program will run clang.
I would recommend trying to use homebrew to install GCC on OS X/MacOS. You do want to be careful about how it gets installed, etc., so that you know which command corresponds to which compiler.
Perhaps a very trivial question:
I need to compile a program as 64-bit (earlier makefile written to compile it as 32-bit).
I saw the option -m32 appearing in command line parameters with each file compilation. So, I modified the makefile to get rid of -m32 in OPTFLAG, but again when the program compiles, I still see -m32 showing up and binaries are still 32-bit. Does this m32 come from somewhere else as well?
-m32 can only be coming from somewhere in your makefiles, you'll have to track it down (use a recursive grep) and remove it.
When I am able to force -m64, I get "CPU you selected does not support x86-64 instruction set".Any clues?. uname -a gives x86_64
That error means there is an option like -march=i686 in the makefiles, which is not valid for 64-bit compilation, try removing that too.
If you can't remove it (try harder!) then adding -march=x86-64 after it on the command line will specify a generic 64-bit CPU type.
If the software you are trying to build is autotools-based, this should do the trick:
./configure "CFLAGS=-m64" "CXXFLAGS=-m64" "LDFLAGS=-m64" && make
Or, for just a plain Makefile:
env CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 make
If you are using CMake, you can add m64 compile options by this:
add_compile_options(-m64)