cannot execute binary file: Exec format error 64bits - bash

I'm under Windows Linux Subsystem which works well on other computer.
I have a 64-bits file: ./ensembles.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
uname -m: x86_64
I tried with the gcc compiler and the clang one, both loose.
Even this C code doesn't work:
#include <stdio.h>
#include <stdlib.h>
#include "sac.h"
#include "type_ensemble.h"
#include "operations_ens.h"
int main(int argc, char ** argv) {
}
The error: -bash: ./ensembles.o: cannot execute binary file: Exec format error
My Makefile:
ensembles.o : ensembles.c sac.h type_ensemble.h operations_ens.h
gcc -c ensembles.c
operation_ens.o : operations_ens.c operations_ens.h
gcc -c operations_ens.c
sac.o : sac.c sac.h
gcc -c sac.c
main: ensembles.o operation_ens.o sac.o
gcc -o main ensembles.o operation_ens.o sac.o

A file of type ELF 64-bit LSB relocatable is a file of ELF type ET_REL, which is not directly executable. It's commonly called an object file or .o file, and it is an input file for the link editor.
You need to link it (either with the gcc or the ld command) to produce an executable. If you are invoking gcc, you must not pass options like -r or -c, or otherwise GCC will not produce an executable.
In the makefile you quote, only the first target will be executed by make because it is the default target. Try moving the rule for main to the beginning of the file, or add a rule
all: main
at the beginning. You can also invoke make main to request building the main file explicitly.

Related

Solaris 8's gcc isn't searching for header files on NetBSD

I have a gcc 2.95.1 binary installed on a Solaris 8 VM. For an experiment, I'm trying to get it working in a NetBSD environment. However, I can't run the compilation phase on any program that involves #include directives, as the binary doesn't seem to be looking for libraries even without the -I flag specified. The example that I'm trying to test out now is a simple Hello World:
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("Hello World!\n");
exit(0);
}
Running gcc -I some_random_directory -v -o hello_world.o -c hello_world.c on the Solaris 8 machine produced this:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/specs
gcc version 2.95.1 19990816 (release)
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/cpp -lang-c -v -I some_random_directory -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) hello_world.c /var/tmp/ccA6aEZ8.i
GNU CPP version 2.95.1 19990816 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
some_random_directory
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/../../../../sparc-sun-solaris2.8/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/../../../../include/g++-3
End of omitted list.
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/cc1 /var/tmp/ccA6aEZ8.i -quiet -dumpbase hello_world.c -version -o /var/tmp/ccUTCLhe.s
GNU C version 2.95.1 19990816 (release) (sparc-sun-solaris2.8) compiled by GNU C version 2.95.1 19990816 (release).
Running the same compilation command using the Solaris 8 gcc on NetBSD produced this:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/specs
gcc version 2.95.1 19990816 (release)
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/cpp -lang-c -v -I some_random_directory -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) hello_world.c /var/tmp/ccFedUPd.i
GNU CPP version 2.95.1 19990816 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
.
.
.
.
.
End of search list.
The following default directories have been omitted from the search path:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.1/../../../../include/g++-3
End of omitted list.
hello_world.c:1: stdio.h: No such file or directory
hello_world.c:2: stdlib.h: No such file or directory
At first, I thought gcc was just ignoring the -I flag, but the other search locations aren't showing up in the second output either. What might be going on here?
Even if you succeed with a compilation, it is unlikely that the toolchain will produce usable executables. However, to address the original question...
You need to override the compiler's idea of system include and library paths. To do this, you use -nostdinc, -isystem, -isysroot and --sysroot command line options.

How to compile a file using a shared library?

I am trying to compile a source given a .so file libfoo.so. The only thing in this library is a function that just returns a number (yeah, I know, advanced stuff). The header file equivalent (I was provided with both, but am only supposed to use the .so) is named foo.h and the function is named int foo().
My source file is main.c:
#include <stdio.h>
#include "foo.h"
int main()
{
int x = foo();
printf("%d", x);
return 0;
}
Now, when trying to compile I have the following commands:
gcc -Wall -fPIC -c main.c -o main.o
gcc -Wall -fPIC main.o -o main -lfoo -L.
The first command fails to create the object file, outputting the following error:
fatal error: foo.h: No such file or directory
I am using Ubuntu 16.04.
I have also tried exporting the current location to LD_LIBRARY_PATH as I've seen suggested on a few other answers.
export LD_LBIRARY_PATH=$LD_LIBRARY_PATH:machine/Desktop/lib_test
You need to have the interface definition from the .h file and that file must be in the current directory or a directory on the include search path.
Note that on some systems filenames and paths are case dependent.

Problem compiling program using fork in cygwin

I am trying to run a simple program in cygwin that includes fork and wait.
I thought it would be very easy to compile but I am having problems.
#include <stdio.h>
#include <unistd.h>
void testFork(){}
int main(int argc,char* argv[]){
if (fork()==0) {testFork();return 0;}
while (wait() == -1);
return 0;
}
Compiled using:
gcc -Wall -Wextra -o test.o test
I get the following error:
C:\Users\Aaron\AppData\Local\Temp\ccgh3MfS.o:ostest.c:(.text+0x11): undefined reference to `fork'
C:\Users\Aaron\AppData\Local\Temp\ccgh3MfS.o:ostest.c:(.text+0x22): undefined reference to `wait'
collect2: ld returned 1 exit status
I'm sure I'm missing something trivial. Any ideas?
The linker can't find the standard C libraries.
Did you install Cygwin in the normal way? (Here's a simple guide: http://www.eecg.utoronto.ca/~aamodt/ece242/cygwin.html).
Have you been able to compile even simpler programs:
#include <stdio.h>
int main(int argc, char **argv) {
printf("Found C library.\n");
}
If that doesn't compile, you might just want to try removing and reinstalling Cygwin - something is broken.
C:\Users\Aaron\AppData\Local\Temp\ccgh3MfS.o is a Windows-style path. If you're using Cygwin, you only be seeing Cygwin-style paths, perhaps something like /cygdrive/C/Users/Aaron/AppData/Local/Temp/ccgh3MfS.o.
You said your command line was
gcc -Wall -Wextra -o test.o test
but it was probably
gcc -Wall -Wextra -o test.o test.c
Are you invoking gcc from the Cygwin command line? What does type gcc say?
It seems that MinGW gcc is being invoked because the cygwin gcc package is not installed.
You can verify that by calling the "cygcheck -c" in the cygwin commandline which will list all the installed packages, if you can't find the gcc in the list you need to install it

What's the difference between gcc and g++/gcc-c++?

It seems to me that gcc can deal with both c and c++ projects,so why is g++/gcc-c++ needed?
What's the difference between g++ and gcc-c++?
gcc will compile C source files as C and C++ source files as C++ if the file has an appropriate extension; however it will not link in the C++ library automatically.
g++ will automatically include the C++ library; by default it will also compile files with extensions that indicate they are C source as C++, instead of as C.
From http://gcc.gnu.org/onlinedocs/gcc/Invoking-G_002b_002b.html#Invoking-G_002b_002b:
C++ source files conventionally use one of the suffixes .C, .cc, .cpp, .CPP, .c++, .cp, or .cxx; C++ header files often use .hh, .hpp, .H, or (for shared template code) .tcc; and preprocessed C++ files use the suffix .ii. GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).
However, the use of gcc does not add the C++ library. g++ is a program that calls GCC and treats .c, .h and .i files as C++ source files instead of C source files unless -x is used, and automatically specifies linking against the C++ library. This program is also useful when precompiling a C header file with a .h extension for use in C++ compilations.
For example, to compile a simple C++ program that writes to the std::cout stream, I can use either (MinGW on Windows):
g++ -o test.exe test.cpp
gcc -o test.exe test.cpp -lstdc++
But if I try:
gcc -o test.exe test.cpp
I get undefined references at link time.
And for the other difference, the following C program:
#include <stdlib.h>
#include <stdio.h>
int main()
{
int* new;
int* p = malloc(sizeof(int));
*p = 42;
new = p;
printf("The answer: %d\n", *new);
return 0;
}
compiles and runs fine using:
gcc -o test.exe test.c
But gives several errors when compiled using:
g++ -o test.exe test.c
Errors:
test.c: In function 'int main()':
test.c:6:10: error: expected unqualified-id before 'new'
test.c:6:10: error: expected initializer before 'new'
test.c:7:32: error: invalid conversion from 'void*' to 'int*'
test.c:10:9: error: expected type-specifier before '=' token
test.c:10:11: error: lvalue required as left operand of assignment
test.c:12:36: error: expected type-specifier before ')' token
As far as I know, g++ uses the correct C++ linker options whereas gcc uses the C linker options (so you may get undefined references, etc.).

How to set the dynamic linker path for a shared library?

I want to compile a shared library with an .interp segment.
#include <stdio.h>
int foo(int argc, char** argv) {
printf("Hello, world!\n");
return 0;
}
I'm using the following commands.
gcc -c -o test.o test.c
ld --dynamic-linker=blah -shared -o test.so test.o
I end up without an INTERP segment, as if I never passed the --dynamic-linker=blah option. Check with readelf -l test.so. When building an executable, the linker processes the option correctly and puts an INTERP segment in the program header. How to do I make it work for shared libraries too?
ld doesn't include a .interp section if -shared is used, as #MichaelDillon already said. You can however provide this section yourself.
const char interp_section[] __attribute__((section(".interp"))) = "/path/to/dynamic/linker";
The line above will save the string "/path/to/dynamic/linker" in the .interp section using GCC attributes.
If you're trying to build a shared object that's also executable by itself, check this question out. It has a more comprehensive description of the process.
The INTERP segment only goes into binaries which need to load the ELF interpreter (ld.so) in the first place. A shared library has no INTERP segment because the ELF interpreter is already loaded before the shared library is loaded.
In most linux systems the ldconfig is run at every system boot and it looks definitions in /etc/ld.so.conf for looking in directories that have shared libraries. In the file /etc/ld.so.cache there are mappings for shared libraries sonames and the library full path. Consider reading this article: http://grahamwideman.wordpress.com/2009/02/09/the-linux-loader-and-how-it-finds-libraries/#comment-164

Resources