I am new to the clang++ compiler flags. I have an issue regarding compilation. Here is my cmd:
clang++ -I ../llvm-project/llvm/include -I ../llvm-project/clang/include
-I ../llvm-project/build/tools/clang/include -I ../llvm-project/build/include
-O3 -c $(llvm-config-7 --cxxflags)
projectToTestHeadersBuilding.cpp -o projectToTestHeadersBuilding
I am getting error:
./projectToTestHeadersBuilding: cannot execute binary file: Exec format error
After execution I have projectToTestHeadersBuilding file. But I can not run executable. Can you please help me to understand how to get executable, so I can run it using ./projectToTestHeadersBuilding ?
In your initial command you use the -c flag which makes clang output an object file. This is part of a compiled program but not a complete executable, in order to get the final executable you must perform a linking step, usually with other object files.
A simple compilation can be done as so:
clang++ projectToTestHeadersBuilding.cpp -c -o projectToTestHeadersBuilding.o
clang++ projectToTestHeadersBuilding.o -o projectToTestHeadersBuilding
./projectToTestHeadersBuilding
Generally we do not need to explicitly pass all those -I flags you have passed. If they are needed with your setup, add them to the commands I've included above.
Related
the program no run. how to fix it ( i use C-Free 4.0)
? g++.exe : cannot specify -o with -c or -S and multiple compilations
Can you include the entire build command that you are using? My guess is that you are trying to compile multiple files into an executable in a single command (such as g++ file1.cc file2.cc file3.cc -o file.exe), but you've also got a -c flag in the commpilation command.
For reference, normally when you compile, two things happen. First, source code gets turned into machine code. Second, machine code gets linked to produce an executable.
In gcc/g++, you can compile one source file into machine code by using the -c flag. You can link one (or many) machine code file(s) into an executable by using the -o flag. There's a shorthand where you can compile and link all in one step using the -o flag (but that's generally not a good idea, because then any change to any file requires you to recompile everything).
As for -S, that's for when you want to generate assembly code from source code. I'm guessing that's not what you are doing, though.
Here's an example, just to round it all out. Suppose that you have files file1.cc and file2.cc, and there is a main() function in file1.cc. Then you can create machine code like this:
g++ file1.cc -c
g++ file2.cc -c
This will result in there being two new files, file1.o and file2.o.
Next, you can link them like this:
g++ file1.o file2.o -o file.exe
This will produce file.exe, the final executable that you can run.
I'm trying to compile a simple program in c++ with gsl. On our university server we have installed GSL. The main problem is, that I'm compilling:
g++ atest.cpp -c -lgsl -lgslcblas -c lm
And after that, I'm typing:
./a.out
And I get :
-bash: ./a.out : No such file or directory
What's the problem? Thanks.
You're only compiling, not linking. From man gcc:
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
By default, the object file name for a source file is made by
replacing the suffix .c, .i, .s, etc., with .o.
Unrecognized input files, not requiring compilation or assembly,
are ignored.
So -c option (command line argument) means compile
g++ atest.cpp -c -lgsl -lgslcblas -lm
g++ atest.o
this will produce a.out file, or you can use short hand
g++ atest.cpp -lgsl -lgslcblas -lm
which will compile and link code in one.
Plus, you could use ls to check your directory does it contain a.out before trying to run it.
When I want to run a source code why this works :
gcc test.c -o test.o
then
./test.o
but this does not work :
gcc -c test.c
then
./test.o
and get this message
bash: ./test.o: Permission denied
First of all, you are not creating an object file but an executable file. Object files are an intermediate file used as input file for the linker to create the executable file. That you name it with an .o suffix doesn't matter.
Secondly, due to tradition if you do not specify an output filename with the -o option the compiler frontend program and linker will create an executable named a.out.
But that's not all, because with the second example you are actually creating a real object file, and those are not executable. Like mentioned above, those needs to be passed to a separate linking step to create the executable file.
You either need to create an executable file:
gcc test.c
./a.out
Or you should link the object file into an executable file:
gcc -c test.c # Create object file
gcc test.o -o test # Use object file to create executable file
./test # Run the executable file
You get that message because the compiler doesn't set the executable bit on object files, because - well, because they are not executable. If you set the executable bit manually and try to run it, you'll get something like "unknown executable format".
Now, it's not just a format problem - the point is that an object file is just half of the work to get something that can actually be executed. In particular, it's missing the linking step, where the linker finds unresolved references and patches them with the addresses from other object files - including the ones you don't specify explicitly, like the standard library - and generates a proper executable file, that the kernel knows how to load and execute.
In the first case you just name the resulting file test.o by using -o, it has been compiled assembled and linked.
In the second case you merely compiled and assemble, it can't run without being linked. See gcc --h or Overall options for gcc for -c:
-c
Compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an object file for each source file.
By default, the object file name for a source file is made by replacing the suffix ‘.c’, ‘.i’, ‘.s’, etc., with ‘.o’.
Unrecognized input files, not requiring compilation or assembly, are ignored.
(Emphasis mine)
You need to link it and then execute it:
gcc -o a.out test.o
You cannot run an object file. This is not executable and need to be linked to become executable.
Try
gcc -o test test.c and run using ./test.out
This is a fundamental question in gcc. Note that never using parameter -c when you want to get an executable file in single command such as
gcc -c xx.c yy.c -o new
.But you can get an executable file with -c in following commands
gcc -c xx.c yy.c
gcc xx.o yy.o -o new
It's equivalent to
gcc xx.c yy.c -o new
I've tried to add the following lines to my makefile in order to add some MATLAB plots to my C++ routine, to set the environment variables:
export PATH='/APP/MATLAB/R2013a/bin':$PATH
export LD_LIBRARY_PATH='/APP/MATLAB/R2013a/bin/glnxa64:/APP/MATLAB/R2013a/sys/os/gnlxa64':$LD_LIBRARY_PATH
And to provide the code with the correct location for the include files at compilation time:
.cpp.o:
g++ -c -DUNIX $(DEBUG) -I $(NR_DIR):/APP/MATLAB/R2013a/extern/include/ $<
$(CMD): $(OBJ)
g++ -o $# $(OBJ) -L$(NR_DIR) -lnr -DUNIX -I $(NR_DIR):/APP/MATLAB/R2013a/extern/include/
Where I've only added :/APP/MATLAB/R2013a/extern/include/ to the includes.
The compilation runs normally, except that the one .cpp file I've made changes to (which is the one that requires the new includes) sends the following error:
which sounds like I should install g++ but how could that be if g++ is run for all the other files properly and it's also working just fine compiling the original program?
I would like to know if I am making a mistake in the compiler call and if the exports are not all right. This is working properly on my laptop but now that I've tried to migrate the program to our school's cluster it's become messy.
The -I option to g++ does not presume a semicolon-divided directories list. This means you have to use -I option for each directory. Example:
-I $(NR_DIR) -I/APP/MATLAB/R2013a/extern/include
I am very aware of compiling C++ programs with g++ in linux environment. But, may be I am missing something, I am getting this strange output/behaviour.
I have source file in test.cpp.
To compile this, I did
(1)
g++ -c test.cpp
g++ -o test test.o
./test
Everything works fine.
But when I did compling and linking in same stage, like this
(2)
g++ test.cpp -o test
./test => Works fine
(3)
g++ -c test.cpp -o test => Doesn't work
In my last case, test is generated but is no more executable; but in my guess it should work fine.
So, what is wrong or do I need to change some settings/configuration ??
I am using g++ 4.3.3
Thanks.
When you say:
g++ -c test.cpp -o test
The -c flag inhibits linking, so no executable is produced - you are renaming the .o file.
Basically, don't do that.
You are forcing compiler to produce an object file and name it like an executable.
Essentially your last line tells: compile this to an object file, but name it test, instead of test.obj.
-c flag means Compile Only
Try
g++ -o test test.cpp
Specifying -o in the g++ command line tells the compiler what name to give the output file. When you tried to do it all in one line, you just told the compiler to compile test.cpp as an object file named test, and no linking was done.
Have a look at the fabulous online manual for GCC for more details.
from the gcc manual:
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
You must link the compiled object files to get the executable file.
More info about compiling and linking and stuff is here.
Read man g++. The switch -c is to compile only but not to link.
g++ -c test.cpp -o test
does what
g++ -c test.cpp
does but the object file will be test istead of the default name test.o. An object file cannot be executed.