I always use the file command to check the file type, mostly after I compile a new project to make sure everything is fine.
The output is something similar to this below:
proj_out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=0x23d9f966854e09d721c6110d505247483dae02fe, stripped
My question is since my Linux Kernel is updated to 3.0+, why does it still shows it is compiled for older versions of Linux?
for GNU/Linux 2.6.24
Is it anything related to file command or do I have to do anything to compile my project against newer Linux Kernel?
Thanks
The kernel version displayed by file on an executable has nothing to do with the kernel installed on your system. It matches the C library the program was linked with at build time.
Your C compiler targets a specific C library (usually glibc). In turn, the C library targets a kernel API (i.e. the C library is built for a specific kernel). That is the version displayed by file.
You don't have to worry about the mimatch between the kernel version displayed by file and the kernel version installed on your machine.
#REALFREE: you can try the following experiment. Maybe it will
help you get a grasp of what's going on:
$ uname -r
3.10-2-amd64
$ gcc -Wall -Werror hello.c -o hello
$ readelf --notes ./hello
Displaying notes found at file offset 0x0000021c with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.32
The information about the ABI tag is contained in an elf
segment called NOTE. This information is written by the linker
when the program is compiled. It matches the ABI tag of the C library.
$ ldd ./hello
linux-vdso.so.1 (0x00007fffd31fe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5f1a465000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5f1a827000)
$ readelf --notes /lib/x86_64-linux-gnu/libc.so.6
Displaying notes found at file offset 0x00000294 with length 0x00000020:
Propriétaire Taille des données Description
GNU 0x00000010 NT_GNU_ABI_TAG (étiquette de version ABI)
OS: Linux, ABI: 2.6.32
In order to build the C library, you have to select a kernel
version. Here, the C library was compiled for a 2.6.32 kernel but
it also works with more recent kernels. However, if the program
is run on a kernel older than 2.6.32, a kernel too old warning
is displayed.
That version number refers to the kernel headers from which the glibc C library was built on the host that the compiler was run on. Broadly, it shows the level of kernel that the executable will be expected to support.
Related
I have two ELF binaries on my Linux machine. When I run file on them I receive the following:
File#1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.0, not stripped
File#2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
Now as far as I understand it, the for GNU/Linux 2.2.X part stems from the .note.ABI-tag section of the binary and is added by the linker. The resulting value of 2.2.X depends on the version of the C library that is linked to the binary and describes the lowest ABI version that this C library version supports - meaning that File #1 will be supported on machines with a Linux kernel >= 2.2.0 and File #2 on machines with a Linux kernel >= 2.2.5. (Is that correct, or am I already wrong here?)
I would suppose that the differences in the ABI tag would stem from two different C library versions contained in the two binaries. But when I examine the strings of the binaries, both of them contain the string glibc 2.3.2.
How is this possible? It seems unreasonable to me, that a patch of some sort to the GNU C Library which didn't result in a version number change would change the supported ABI version...
The glibc ABI is supposed to be independent of the kernel version it is built for, and the test suite attempts to verify that a newly built glibc conforms to the official ABI.
The minimum kernel version required by a glibc release can be specified at glibc configure time, and this is what ends up in the .note.ABI-tag section. No patching of the glibc sources is needed. I'm not entirely sure whether it is correct that the configured minimum kernel version ends up in dynamically linked binaries (because it should be possible to run the binaries on older kernels with a differently built glibc).
However, for statically linked binaries, this is certainly correct because configuring a higher minimum kernel version will make the program fail to run on older kernels.
I am trying to cross-compile a binary to use on an old Linux distribution (kernel 2.4.25, i586 architecture).
Steps I took
I have downloaded the landley i586 cross-compiler (http://landley.net/aboriginal/downloads/binaries/)
I downloaded the net-utils source: https://ftp.gnu.org/gnu/inetutils/ version 1.9.4
I included the cross-compiler in my path: export PATH=/root/Documents/cross-compiler-i586/bin/:$PATH
I then built the telnet binary as follows: LDFLAGS=”-static" ./configure --host=i586 --build=x86_64 --target=i586 --disable-ifconfig --with-ncurses-include-dir=/root/Documents/tnbuild --disable-hostname --disable-logger --disable-rcp --disable-rexec --disable-rlogin --disable-rsh --disable-tftp --disable-traceroute --disable-inetd --disable-rexecd --disable-syslogd --disable-tftpd
This successfully compiled, and checking (after stripping) the binary with the file command gives: telnet: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
I compared this with a binary which is already on the old Linux system, and the output is exactly the same: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter lib/ld-linux.so.2, for GNU/Linux 2.4.0, stripped
The problem I am facing
The telnet binary that I compiled is not working on the old Linux system. The error that is thrown is simply 'Segmentation Fault'. Googling this error learns that it is likely due to differences in architecture (i586?), but I have no clue anymore how to fix it, as the 'file' command outputs exactly the same for a working binary as well as for the failing binary.
I then stumbled across this topic: GCC Cross compile to a i586 architecture (Vortex86DX) , but as it is not pursued, I am not sure if I should indeed compile all toolchains for i586 and how exactly I would need to do that.
Is there a specific reason you want to cross-compile this rather than just compiling for generic 32-bit i386? You may need to disable some compiler optimizations if they are not supported by the CPU, but you probably don't need to create a staticly-linked binary.
These instructions for compiling 32-bit (-m 32) seem sufficient to create the telnet binary.
They boil down to:
apt-get install gcc-multilib;
./configure CFLAGS='-m32' -disable-ifconfig \
--with-ncurses-include-dir=/root/Documents/tnbuild \
--disable-hostname --disable-logger --disable-rcp \
--disable-rexec --disable-rlogin --disable-rsh \
--disable-tftp --disable-traceroute --disable-inetd \
--disable-rexecd --disable-syslogd --disable-tftpd
make
I was given a "binary" file on linux and a seperate file for windows for a particular task. The programs is an exe on windows. A linux version of the file has the same function on linux as it had windows, too.
However, I've failed to be able to execute this. I tried (on the terminal) to execute it by just the file name, ./[filename], and even tried chmod +x [filename] and then tried the second way.
For everything... I get the result: "Command not found". (The file is definitely there, by the way).
What am I supposed to do? The file command on it yields:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e805f746e65c09cc8b0c037d8a8c27ee0a6a051c
My guess is that this is 32 bit compile on a 64 bit system. I cross compiled a small c file into a binary using the -m32 option on gcc. This also needed a few extra packages. The resulting a.out looks like this.
% file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=be02470c8337b96e7deaaff323bc53865991c3ab, not stripped
Compare this to a native system binary
% file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a0823e17cafbe5b2296346216445566840fdfd88, stripped
Running the a.out shows me this.
% ./a.out
zsh: no such file or directory: ./a.out
The specific "Command not found" message is something, I think, bash prints. I use zsh myself.
To get this to work, you can install the multilib packages. I didn't narrow it down to the exact package but installing gcc-multilib on Debian pulls in everything you need. After installing that, here's what I get.
% ./a.out
3.140523
(the program is supposed to estimate the value of PI).
Note: I actually needed to install gcc-multilib just to compile the file. I then uninstalled the packages to mimic a 64 bit system that doesn't have the 32 bit runtime libraries that the thing needs.
does the a.out have executable permission ?
check with ls -la cmd and if does no then add the permission using chmod a+x a.out an d then try executing
Can someone explain the difference between the three architectures?
Actually when I built a 64-bit application in Linux, I got a link error saying:
skipping incompatible library.a when searching for library.a
Then I used objdump -f on that library and I got the below output:
a.o: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
Does it mean the library is 32-bit? Is that the reason I am getting the linker error?
There are 3 common ABIs usable on standard Intel-compatible machines (not Itanium).
The classic 32-bit architecture, often called "x86" for short, which has triples like i[3-6]86-linux-gnu. Registers and pointers are both 32 bits.
The 64-bit extension originally from AMD, often called "amd64" for short, which has GNU triple of x86_64-linux-gnu. Registers and pointers are both 64 bits.
The new "x32" ABI, with a triple of x86_64-linux-gnux32. Registers are 64 bits, but pointers are only 32 bits, saving a lot of memory in pointer-heavy workflows. It also ensures all the other 64-bit only processor features are available.
Each of the above has its on system call interface, own ld.so, own complete set of libraries, etc. But it is possible to run all 3 on the same kernel.
On Linux, their loaders are:
% objdump -f /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2
/lib/ld-linux.so.2: file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000a90
/lib64/ld-linux-x86-64.so.2: file format elf64-x86-64
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000000c90
/libx32/ld-linux-x32.so.2: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000960
Now, if you're getting the message about "skipping incompatible library", that means something is messed up with your configuration. Make sure you don't have bad variables in the environment or passed on the command line, or files installed outside of your package manager's control.
Beyond usual full 64bit and good old 32bit ABI there is a special ABI (inspired by SGI n32 envirnment) where pointers are 32bit (thus they are 32bit apps), but it is designed to run on 64bit host and have full access to all x64 goodies:
native x64 registers and math
more registers
SSE2/3/4, AVX1/2/...
Full 4Gb address space on 64bit host
It is called x32 ABI, link: https://en.wikipedia.org/wiki/X32_ABI
UPDATE
On Ubuntu system I have to install two packages (with deps) to get x32 working:
> sudo apt install gcc-multilib
> sudo apt install libx32stdc++-5-dev
Then compiling simlple C++ code with g++ -mx32 hellow.cpp works, making x32 executable
> file a.out
./a.out: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0
I can not find any built versions of the binutils that could be pushed to an Android device an then be executed from there. The Android NDK toolchain provides them but in the wrong format.
Devices need them in ELF 32bit executable for ARM , but the toolchain only provides :
compiledtoolchain/bin$ file arm-linux-androideabi-objdump
arm-linux-androideabi-objdump: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
Does anyone know if and where to find objdump in a format so that it can be executed directly on an ARM android device ?
I haven't tried it on an Android device, but you might want to look at the pre-built binaries of my ELLCC cross compiler project: ftp://ellcc.org/pub (http://ellcc.org). Each tarball contains binaries for the clang/LLVM based C/C++ compiler, pre-built libraries, gdb, and the GNU binutils. All of the executables are statically linked so they don't rely on any shared libraries being available on the target system.