Why I cannot run an object file?
An object file is not machine instructions. It is not intended to be run. It is intended to be linked. You should use gcc test.c -o test . Then you have a runnable file called test .
Take a good look a man ld and see what purpose it serves in creating the final elf-executable and see the answers (as well as Joachim’s deleted one) below.
Not to be rude, but this is somehow analogous to asking, why I can rename a .pdf to .doc but can’t open the new file using MSWord. 🙂
5 Answers 5
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:
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 How to run c program with .so file
and I have generated .so file for the same with name t.so and header file t.h` Now I would like to use this function in my C program.
I have written the code but I don’t know how to execute it.
./a.out Error while loading shared libraries: t.so: can not open shared object file: no such file or directory exists. 4 Answers 4
You should use the linker option -rpath , which tells the linker to add information in the executable program where to find runtime libraries like your .so file.
This can be done using the GCC option -Wl which instructs the GCC frontend program to pass an option to the linker:
This will pass -rpath=$(pwd) to the linker, and $(pwd) causes the shell to call the pwd command to return the current directory.
As long as you don’t move the library the program should work.
You can use the environment variable LD_LIBRARY_PATH too, but it’s not recommended.
Most probably your loader cannot find the library. Try to put the path to the directory where the libarry is located to LD_LIBRARY_PATH prior to run your binary.
export LD_LIBRARY_PATH=/path/to/my/library ./a.out .so files are shared object, meaning object that are available to all applications that need them.. that is, shared. Due to this characteristics, they need to be stored in a well known place. Also, they need to be indexed by the dynamic linker.
In linux for instance you typically have a file /etc/ld.so.conf where all directories where shared object are automatically read from are stored
- Put your shared object file in a well known place
- Put your shared object file in a place of your choice and let the dynamic linker know about it: in linux you can modify ld.so.conf and run ldconfig to update ld indexes
- As other suggested write the path of your .so in the env variable LD_LIBRARY_PATH (since dynamic linker reads it before running your application). This must be done at each environment creation
- As other suggested use -rpath when compiling. Note that in this way you cannot move your .so file after the compilation
Personally I prefer installing the .so file in a system library path
How to run binary file in Linux
I have a file called commanKT and want to run it in a Linux terminal. Can someone help by giving the command to run this file? I tried ./commonRT but I’m getting the error:
"bash: ./commonrt: cannot execute binary file" [blackberry@BuildMc MainApp]$ ls -al commonKT -rwxrwxr-x. 1 sijith sijith 10314053 Feb 27 16:49 commonKT Assuming the problem isn’t just a mixup over names ( commonrt vs commonKT ), what does the command file commonKT /bin/sh say? If it gives two different architectures (perhaps one for ARM and one for Intel), then that’s why you can’t run the ARM one on an Intel machine.
In addition of using file , I also suggest using ldd ; perhaps the dynamic linker or some core shared library is different or missing.
Why does this question have so many upvotes? It contains so many variants of the questioned filename (commonrt, commonKT, commanKT, commonRT), that it’s not even clear what was asked. Also interesting: Does the last comment of Sijith mean that it is answered? And why did user1978011 receive bountys?
13 Answers 13
To execute a binary, use: ./binary_name .
bash: ./binary_name: cannot execute binary file
it’ll be because it was compiled using a tool chain that was for a different target to that which you’re attempting to run the binary on.
For example, if you compile ‘binary_name.c’ with arm-none-linux-gnueabi-gcc and try run the generated binary on an x86 machine, you will get the aforementioned error.
To execute a binary or .run file in Linux from the shell, use the dot forward slash friend
and if it fails say because of permissions, you could try this before executing it
chmod +x binary_file_name # then execute it ./binary_file_name The volume it’s on is mounted noexec .
🙂 If not typo, why are you using ./commonRT instead of ./commonKT ??
It is possible that you compiled your binary with incompatible architecture settings on your build host vs. your execution host. Can you please have a look at the enabled target settings via
on your build host? In particular, the COLLECT_GCC_OPTIONS variable may give you valuable debug info. Then have a look at the CPU capabilities on your execution host via
cat /proc/cpuinfo | grep -m1 flags Look out for mismatches such as -msse4.2 [enabled] on your build host but a missing sse4_2 flag in the CPU capabilities.
If that doesn’t help, please provide the output of ldd commonKT on both build and execution host.
@craq I see that you gave me your bounty, thanks! Can you please give some info what the error was about?
This is an answer to @craq :
I just compiled the file from C source and set it to be executable with chmod. There were no warning or error messages from gcc.
I’m a bit surprised that you had to ‘set it to executable’ — my gcc always sets the executable flag itself. This suggests to me that gcc didn’t expect this to be the final executable file, or that it didn’t expect it to be executable on this system.
Now I’ve tried to just create the object file, like so:
$ gcc -c -o hello hello.c $ chmod +x hello ( hello.c is a typical «Hello World» program.) But my error message is a bit different:
$ ./hello bash: ./hello: cannot execute binary file: Exec format error` On the other hand, this way, the output of the file command is identical to yours:
$ file hello hello: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped Whereas if I compile correctly, its output is much longer.
$ gcc -o hello hello.c $ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=131bb123a67dd3089d23d5aaaa65a79c4c6a0ef7, not stripped What I am saying is: I suspect it has something to do with the way you compile and link your code. Maybe you can shed some light on how you do that?